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Description 

[0001] The present invention relates to an improvement in a system for recording a digital video datastream and, 
more particularly, to a system capable of efficiently recording an MPEG transport stream to be digitally broadcasted. 
The present invention further relates to a system for recording support information of an MPEG transport stream in a 
management area. 

[0002] In recent years, TV broadcast has entered an era of digital broadcast and. hence, the necessity of a 
streamer (an apparatus for saving digital data intact) for digital TV broadcast has come forth. 
[0003] Digital TV broadcast currently uses an MPEG transport stream, which will probably become a standard in 
the field of digital broadcast of moving pictures in the near future. 

[0004] AS a streamer for recording digital broadcast data, for example, D-VHS (digital VHS) is available. 
[0005] Digital TV broadcast data is broadcasted from a broadcast station via a communication satellite. The broad- 
casted digital data is received by a Set Top Box (to be abbreviated as an STB hereinafter as needed) set in each home, 
and is displayed on a TV monitor. This STB decrypts and plays back encrypted digital data on the basis of a key code 
distributed from the broadcast station. 

[0006] Data is encrypted to prevent a user who does not have any contract with the broadcast station from illicitly 
receiving and viewing that data. 

[0007] When the received data is directly played back, it is decrypted by the STB. The decrypted data is decoded 
by an MPEG decoder, and the decoded data is converted into a TV signal by a video encoder to be displayed on a TV 
monitor. 

[0008] When broadcast data is recorded, digital data received by a tuner is recorded by a D-VHS recorder via an 
IEEE1394 digital interface. 

[0009] Note that IEEE1394 specifies standard interface specifications, that implement command and data 
exchanges. 

[0010] When recorded broadcast data is played back, the recorded data is read from the D-VHS recorder, and is 

sent to a data expansion unit in the STB, thus playing back the recorded data. 

[001 1] Digital data recorded by the D-VHS recorder normally has the following structure. 

[0012] That is. digital data to be recorded is recorded as main data in a sync block in a main data area, while six 

tracks are handled as one ECC block. In this case, a header is appended to a transport stream (TS) packet upon 

recording. 

[001 3] In such D-VHS streamer, the broadcasted bitstream is directly recorded on tape. For this reason, a plurality 
of multiplexed programs are recorded on the tape. 

[001 4] Hence, all data are output from the tape upon playback irrespective of the playback start position. The STB 
selects only a desired program from the output data and plays it back. 

[001 5] Such system suffers very poor random-access performance, since a tape medium is used to record. For this 
reason, even when the user wants to quickly reach a desired position of a given program to play it back, such random 
access is impossible to attain. 

[0016] On the other hand, even in large-capacity disc media such as DVD-RAMs and the like, recording of a 
streamer suffers certain problems. To realize random access, special playback, and the like, such DVD system inevita- 
bly requires to record management data together with broadcast data. 

[001 7] Also, in such DVD system, data must be managed or formatted in accordance with the DVD video format. 
[0018] However, since the DVD video format does not assume satellite broadcast, it cannot often support special 
playback or the like. 

[0019] Japanese Patent Application No. JP1 0-040876 has proposed the format that assumes a home 
recorder/player. However, even in this format, digital broadcast is not taken into consideration. 
[0020] As mentioned above, in a digital TV broadcast compatible streamer system, TS stream data cannot be effi- 
ciently managed in a streamer that uses a DVD-RAM capable of random access, i.e., a read/write (R/W) disc. 
[0021] It is an object of the present invention to provide a system that can efficiently record a transport packet in a 
streamer which uses media (DVD-RAM and the like) capable of random access. 
[0022] It is another object of the present -invention to add a streamer function to the DVD video format. 
[0023] It is still another object of the present invention to efficiently manage digital TV broadcast data by proposing 
a novel format that assumes digital TV broadcast. 

[0024] To achieve the object, the present invention uses information medium (including a signal or radio wave) 
which comprises an data object (VOB/SOB) formed of one or more data object units (VOBU/SOBU) each of which 
serves as a prescribed data unit; control information (VOBUI/SOBi) of the data object (VOB/SOB); access unit data 
(AUD) used for accessing an access unit (l-picture, etc.) which is a part of contents of the data object (VOB/SOB), the 
access unit data (AUD) being contained in the control information (VOBUI/SOBI); and a bitstream being formed of a 
series of packets, the bitstream including contents of the data object (VOB/SOB) and contents of the control information 
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(VOBUI/SOBI). 

[0025] This summary of the invention does not necessarily describe all necessary features so that the invention 
may also be a sub-combination of these described features. 

[0026J The invention can be more fully under stood from the following detailed description when taken in conjunc- 
tion with the accompanying drawings, in which: 

FIG. 1 illustrates explanatory views showing the format of an MPEG TS stream; 

FIG* 2 illustrates explanatory views showing the format of an object set which is recorded/played back by a DVD 
recording/playback system according to the present invention; 

FIG 3 illustrates explanatory views showing the format structure of a TS pack shown in FIG. 2; 
FIG. 4 illustrates explanatory views showing the structure of a VOBU which is optimal to the pack structure shown 

in FIG. 3; . 
FIG. 5 illustrates explanatory views showing the structure according to a modification of the TS pack shown in FIG. 

3* 

FIG. 6 illustrates explanatory views showing an example of the format of management information which is used to 
manage a video object set (FIG. 2) as an object to be played back; 
FIG. 7 illustrates explanatory views showing the description contents of PGCI shown in FIG. 6; 
FIG. 8 shows a table including the description contents of C_PBI shown in FIG. 6; 

FIG. 9 illustrates explanatory views showing another example of the format of management information which is 
20 used to manage a video object (FIG. 2) as an object to be played back; 

FIG. 10 shows a table including the description contents of VOBUI shown in FIG. 9; 

FIG. 1 1 illustrates explanatory views showing an example of the format structure of a VOBU or cell shown in FIG. 6; 
FIG. 12 illustrates explanatory views showing an example of the format structure of a cell or PGC shown in FIG. 6; 
FIG 13 illustrates views for explaining an edit process using the cell format structure shown in FIG. 6; 
FIG* U is a block diagram showing the overall arrangement of a DVD recording/playback system according to an 
embodiment of the present invention; 

FIG. 1 5 is a flow chart for explaining a recording process in the format structure shown in FIG. 9; 
FIG. 16 is a flow chart for explaining a recording process in the format structure shown in FIG. 9; 
FIG. 1 7 is a flow chart for explaining a playback process in the format structure shown in FIG. 9; 
FIG. 1 8 is a flow chart for explaining a playback process in the format structure shown in FIG. 9; 
FIG. 1 9 is a flow chart for explaining an FF process in the format structure shown in FIG. 9; 
FIG. 20 is a flow chart for explaining an FF process in the format structure shown in FIG. 9; 
FIG. 21 is a flow chart for explaining an FF process in the format structure shown in FIG. 9; 
FIG. 22 is a flow chart for explaining an interrupt process in the flow charts shown in FIGS. 20 and 21 ; 
35 FIG. 23 is a flow chart for explaining a PAT process in the format structure shown in FIG. 20; 

FIG. 24 shows a data structure of the stream data (corresponding to the MPEG2 transport stream of FIG. 1); 
FIG. 25 shows the internal structure of the stream block header as shown in FIG. 24; 
FIG. 26 shows an internal structure of the sector data header shown in FIG. 24; 
FIG. 27 describes constraints on MPEG specifications for SOB; 
40 FIG. 28 shows the structure of navigation data (corresponding to control information 25 in FIG. 9) contained in DVD 
streamer information (STRI); 

FIG. 29 shows the structure of Stream File Information SFIT shown in FIG. 28; 

FIG. 30 shows the structure of Stream File Information SFI shown in FIG. 29; 

FIG. 31 shows the contents of Stream File General Information SF_GI shown in FIG. 30; 
45 FIG. 32 shows the structure of Stream Object Information (SOBI#) shown in FIG. 30; 

FIG. 33 shows the contents of Stream Object Information General Information SOBI_GI shown in FIG. 32; 

FIG. 34 shows the structure of Access Unit Data AUD shown in FIG. 32; 

FIG 35 shows the contents of Access Unit General Information AU_GI shown in FIG. 34; 

FIG. 36 illustrates an example of correspondence between Access Unit Start Map AUSM (cf. FIGS. 8 and 10) and 
bo stream object units SOBUs (cf. FIGS. 2, 4, and 1 1); 

FIG. 37 illustrates an example of correspondence between Access Unit Start Map AUSM (cf. FIGS. 8 and 10) with 

Access Unit End Map AUEM (cf. FIGS. 8 and 10) and stream object units SOBUs (cf. FIGS. 2. 4, and 1 1); 

FIG. 38 shows the structure of one stream pack (corresponding to TS pack shown in FIGS. 2-4); 

FIG. 39 shows the structure of stream data area in the stream PES packet shown in FIG. 38; and 
55 FIG. 40 shows the contents of the application header at the start of the stream data area shown in FIG. 39. 

[0027] A DVD recorder/player and the format of an optical disc on which the DVD recorder/player can write data 
according to an embodiment of the present invention will be described below with reference to the accompanying draw- 
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ings. 

[0028] The terminology of the format will be briefly explained first. Data is saved on an optical disc in a normal file 
format. A title corresponds to a single movie, and a plurality of titles are stored in a single disc. A group of titles is called 
a title set, which is formed of a plurality of files. Also, a file called a video manager (to be abbreviated as VNIG herein- 
after) is stored on a single disc as information for managing this disc. 

[0029] Furthermore, the title set (to be referred to as VTS hereinafter) is composed of a management information 
file of video title set information (to be referred to as VTSI hereinafter), and a backup file of the VTSI. 
[0030] The video file has a hierarchical structure, and a single file is formed of a plurality of program chains, each 
of which comprises a plurality of programs, each of which comprises a plurality of cells, each of which comprises a plu- 
rality of video object units (to be referred to as VOBUs hereinafter). Each VOBU is formed of a plurality of packs includ- 
ing various kinds of data. Each pack is formed of more than one packets and a pack header. The pack is a minimum 
unit for a data transfer process. Furthermore, the minimum unit for a logic process is a cell, and the logic process is 
done in units of cells. 

[0031] A transport (TS) stream will be explained below. In general, in a method of broadcasting compressed mov- 
ing pictures (e.g., digital TV broadcast, cable broadcast such as the Internet, and the like), a TS stream as a common 
basic format is specified to comply with the MPEG2 specifications. 

[0032] The TS stream is composed of a large number of TS packets 38, as shown by (a) in FIG. 1 . Each TS packet 
38 has a structure shown by (b) to (d) in FIG. 1 and is formed of packet management data field 41 and payload 42, as 
shown by (b) in FIG. 1 . Payload 42 stores encrypted data to be played back. 

[0033] Data to be played back stored in payload 42 includes MPEG video data, Dolby AC3 audio data, MPEG audio 
data, and the like On the other hand, information other than the data to be directly played back includes a program 
association table (PAT), a program map table (PMT), and the like which are required upon playing back data, and also 
electronic program guide (EPG) information. 

[0034] The PAT includes packet identification information (PID) of PMTs in units of programs, and each PMT 
records the PID of video data, audio data, or the like. 

[0035] With this format, as a normal playback procedure of an STB. when the user determines a program based on 
EPG information, a PAT is loaded at the start time of the determined program, and the PID of a PMT of the determined 
program on the basis of the PAT The desired PMT is read out based on the determined PID, the PIDs of video and 
audio packets included in the PMT are determined, and the video and audio data are extracted and played back accord- 
ing to the PIDs. Note that the PAT is sent at intervals of several 100 ms since it is also used in the course of playback. 
[0036] When such TS stream data are recorded on a disc medium such as a DVD-RW (read/write) or the like, these 
data are preferably recorded as digital data. However, since the current maximum bit rate of a DVD-RAM is 10.08 Mbps, 
satellite broadcast data (20 Mbps or more) itself in which all channels are multiplexed cannot be recorded. For this rea- 
son, when such data are recorded, one program must be selected and recorded. 

[0037] When certain data are recorded on a disc medium, other data for managing recorded data are required to 
meet user needs (e.g., to start playback from a desired time of a desired program, to fast forward, and the like). How- 
ever, since the data itself to be played back is encrypted, it is hard to generate management data for the data itself to 
be played back. 

[0038] For this reason, management data is preferably generated using data in a packet header as control data in 
a TS stream packet, or data in a PAT or PMT packet as PSI (program specific information) data of a TS stream. 
[0039] Note that such packet header contents may often include information which is not supported depending on 
the types of satellite broadcast, and may often use neither a PAT nor PMT. Hence, management data cannot often be 
generated in units of satellite broadcast services by the aforementioned method, and data cannot be recorded. 
[0040] To solve this problem, upon recording, information of a packet header used by satellite broadcast, and infor- 
mation indicating the presence/absence of a PAT or PMT are saved in management information, and management data 
is generated in accordance with supported information. To provide only available services upon playback, service con- 
tents are preferably changed in accordance with that support information. 
[0041] As a method of detecting support information, the following two methods can be used. 
[0042] In the first method, support information is received from the STB. The STB varies in units of satellite broad- 
cast services to be received, and is a dedicated apparatus. For this reason, the STB should recognize information per- 
taining to support in advance (upon delivery of STB). Hence, that support information is loaded from the STB at the 
beginning of recording. 

[0043] In the second method, each data to be used is checked upon receiving TS stream data from the STB, and 
if that data is active, it is determined that the information is supported, and the support information is stored. At the 
same time, management data is generated based on the supported information, and the accumulated support informa- 
tion is recorded in a management area of an optical disc as management data. 

[0044] The format that includes support information in management data will be explained below. The first example 
will explain management data that manages data complying with the DVD video format for which the format specif ica- 
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tions have already been standardized. 

[0045] Current DVD video format does not assume satellite broadcast or the like. Hence, when satellite broadcast 
data is recorded and the recorded data is played back in special modes, some special modes can not be supported in 
the status. Hence, to propose recording/playback specifications that comply with current DVD video, the following for- 

5 mat is optimal. A L . . 

[0046] In current DVD video, video object set (VOBS) 30 as an object to be played back has a structure shown by 

(a) to (d) in FIG. 2. 

[0047] More specifically, VOBS 30 shown by (a) in FIG. 2 is defined as one or a set of a large number of video 
objects (VOBs) 31 , as shown by (b) in FIG. 2, and each VOB 31 is defined as one or a set of a large number of cells 32, 
w as shown by (c) in FIG. 2. Furthermore, cell 32 is defined as one or a set of a large number of video object units 
(VOBUs) 33, as shown by (d) in FIG. 2. VOBU 33 is formed of one or a large number of TS packs 34, as shown by (e) 

[0048] 2 In a streamer, streamer objects (SOBS) are defined as those corresponding to the VOBs, and streamer 
object units (SOBUs) are defined as those corresponding to the VOBUs. 
is [0049] In the following, descriptions pertaining to the VOB and VOBU may be interpreted by replacing them by the 
SOB and SOBU, respectively, as needed. 

[0050] As for the structure of VOBU 33, two different format schemes can be proposed. 

[0051 ] In the first scheme, one VOBU 33 is composed of one or more TS packs 34 that record transport streams 
(TS streams). One TS pack 34 shown by (a) in FIG. 3 is formed of pack header 35, packet header 36, substream ID 37, 
so and transport packets (TS packets) 38, as shown by (b) in FIG. 3. The size per TS pack 34 is determined to be 2,048 
bytes and if the pack is smaller than 2,048 bytes, padding packet 39 is inserted to adjust the size. 
[0052] Each TS pack 34 is formed of 10 TS packets 38. and packet header 36 includes a stream ID that describes 
Oxbd indicating a private stream in MPEG2. Also, a substream ID that specifies that data in a packet is a transport 
stream describes OxfO. 

25 [0053] Incidentally, a timestamp (ATS) may be placed at the leading portion of each of the TS packets, as shown by 
(b) in FIG. 3. 

[0054] As shown by (C) in FIG. 3. the second scheme has a packet structure in which 2-byte packet access pointer 
40 is inserted after substream ID 37 in the packet structure of (b) in FIG. 3. The packet access pointer 40 indicates the 
start address of head packet 38 in pack 34. 

30 [0055] For example, in (c) of FIG. 3, since head packet 38 in pack 34 is inserted immediately after packet access 
pointer 40, its relative address is zero. In pack 34 shown by (c) of FIG. 3. since last packet 39 has only 142 bytes while 
each of other packets has 188 bytes, remaining 46 bytes are stored in next pack 34 shown by (d) of FIG. 3. 
[0056] In pack 34 shown by (d) of FIG. 3, since the remaining 46 bytes are inserted immediately after packet access 
pointer 40, last packet 39 is located after the remaining 46 bytes. Hence, "0x2e w indicating the address of last packet 39 

35 is described in packet access pointer 40 of next pack 34. 

[0057] With this packet access pointer 40, a field that must store padding data and cannot be used can be used as 
a storage field of packet data. At this time, if the packet access pointer is Oxffff, it indicates that the head packet is not 
present within a pack. 

[0058] In this case, the head packet must be aligned after packet access pointer 40, as shown in the example of (c) 
40 in FIG. 3. With this structure, packets can be managed in units of VOBUs, and a packet which has a size that cannot 
fall within one pack can be coped with. 

[0059] Portions of a transport stream packet (TS packet) shown by (c) and (d) in FIG. 3 correspond to the following 

case. . . . 

[0060] That is. when one packet is recorded across two sectors upon recording a TS packet, data pieces recorded 
45 in the first and second sectors, respectively, correspond to portions of the TS packet. 

[0061] With this format, when one packet is recorded across two sectors, no padding data need be inserted, thus 
increasing the recording density. 

[0062] In this case, a packet header can record position information indicating "the number of bytes from a refer- 
ence position to the first TS start position of each sector*. As the reference position, for example, the position of a packet 
so header, the head position of a TS packet, the end position of a TS packet, or the adjacent boundary position of succes- 
sive adjacent TS packets, may be used. 

[0063] When the head position of a TS packet is used as the reference position, packet access pointer = 0 in (c) of 
FIG. 3 can be used as the position information. 

[0064] When the end position of a TS packet (or the adjacent boundary position) is used as the reference position, 
55 packet access pointer = 0x2e in (d) of FIG. 3 can be used as the position information. 

[0065] An example of the second scheme that has already been explained will be described in more detail below 
with reference to FIG. 4. VOBU (or SOBU) 33 shown by (a) in FIG. 4 is formed of an integer number of TS packs 34, 
and head TS pack 34 in VOBU (SOBU) 33 has the structure shown by (c) in FIG. 4. 
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[0066] More specifically, the head portion of TS packet 38 is always aligned after packet access pointer 40 in TS 
pack 34, and packet access pointer 40 stores zero relative address. Hence, when VOBU (SOBU) 33 is accessed to 
extract that packet, the head ol that packet matches that of TS packet 38, and TS packet 38 can be extracted and imme- 
diately transferred. TS packets 38 are arranged after head TS pack 34 in VOBU (SOBU) 33, and the remaining portion 
of TS packet 38 that cannot be stored in one pack with 2,048 bytes is stored in packet 38 of next TS pack 34, as shown 
by(c)in FIG. 4. 

[0067] In this manner, TS packs 34 are arranged in turn in VOBU (SOBU) 33. Last TS pack 34 in that VOBU 
(SOBU) 33 cannot often store one TS packet 38 at the end of that pack unlike other TS packs 34, as shown by (C) in 
FIG. 4. 

[0068] In such case, padding packet 39 can be inserted in that end portion, as needed. By inserting the padding 
packet, head TS pack 34 in next VOBU (next SOBU) 33 can have a packet data field starting from head TS packet 38. 
[0069] Note that a method that can cope with the aforementioned case without using any padding packet (one 
packet is recorded across two sectors upon recording a TS packet) is also available, and has already been explained. 
[0070] In the example shown in FIGS. 3 and 4, packet access pointer 40 designates the address of first TS packet 
38 in that pack 34, and TS packet 38 to be extracted first in that pack 34 can be specified when pack 34 is designated 
by packet access pointer 40. 

[0071] The structure of next TS pack 34 may be specified by a continuous packet flag shown by (a) and (b) in FIG. 
5, in place of packet access pointer 40. 

[0072] More specifically, as shown by (a) in FIG. 5, substream ID 37 that specifies TS packets is inserted after 
packet header 36 in TS pack 34, and continuous packet flag 41 is inserted after the substream ID. Continuous packet 
flag 41 indicates whether or not TS pack 34 that follows TS pack 34 including that flag stores a portion of TS packet 39. 
[0073] That is, if continuous packet flag 41 is 1 , a portion of TS packet 39 is stored at the end of that TS pack 34, 
and the remaining portion of that TS packet 39 is stored after continuous packet flag 41 in next TS pack 34. 
[0074] If a TS packet 39 is aligned and arranged at the end of TS pack 34 and no portion of that packet remains to 
be stored in next pack 34, zero continuous packet flag 41 is set. This means that if TS packet 39 with zero continuous 
packet flag 41 is acquired, a smooth playback process is assured by playing back TS packet 39 that follows continuous 
packet flag 41. 

[0075] The structure of management data in the aforementioned data structure will be described below. 
[0076] Management data is recorded in a management area after a lead-in area on the inner periphery side of an 
optical disc, and the management area includes a table of video title set information (VTSI) or a table of streamer control 
information (STRVMGI), as shown by (a) in FIG. 6. The STR_VMGI is contained in management information (STRI) 
of a streamer, and the STRI has functions corresponding to those of the VTSI. 

[0077] As shown by (a) in FIG. 6, this VTSI (STR_VMGI) includes a VTSI management table (VTSI_MAT) that 
describes management information pertaining to the VTSI (STR_VMGI); a VTS search pointer table (VTS_TT_SRPT) 
that describes search pointers used to search for a VTS (video title set) or a play list search pointer table (PL_SRPT) 
that describes search pointers used to search for a play list in a stream; a VTS program chain information table 
(VTS__PGCIT) that specifies the cell playback order or a user-defined program chain information table (UD_PGCIT); a 
VTS menu program chain information unit table (VTSM_PGC1JJT); a VTS time map table (VTS_TMAPT); a VTS menu 
cell address table (VTSM_C_ADT); a VTS menu VOBU address map table (VTSM_VOBU_ADMAP); a VTS cell 
address table (VTS_C_ADT); and a VTS VOBU address map table (VTS_VOBU_ADMAP) in this order. 
[0078] User<Jef ined PGC information (UD_PGCI) in the UD_PGCIT is a sequence of parts of a program. The play 
list may be used by a user to freely define the playback sequence of the parts of programs. 

[0079] The VTS.PGCIT (UD_PGCrT) contains VTS_PGCIT information (VTS„PGCITI) (or UD_PGCITI); VTS pro- 
gram chain search pointers (VTS_PGC_SRP#n) (or UD_PGC_SRP#n) arranged in the playback order, and VTS pro- 
gram chain information (VTS_PGCI#n) (or UD_PGCI#n) designated by each of these search pointers, as shown by (b) 
in FIG. 6. 

[0080] As shown by (c) in FIG. 6, the VTS_PGCI#n (or UD_PGCI#n) is made up of program chain (PGC) general 
information (PGC_GI) or stream cell general information (SC_GI); a PGC program map (PGC_PGMAP) or program 
information (PGI#m); a cell playback information table (C„PBIT) that describes information pertaining to cell playback, 
or stream cell information (SCI#n); and a cell position information table (C_POSfT) that describes cell position informa- 
tion, i.e., address information or stream cell information search pointers (SCI_SRP#n). The C_PBIT (SCI#n) is formed 
of a number of pieces of cell playback information (C_PBI#j) which are arranged in the cell playback order, or a number 
of pieces of stream cell entry point information (SC_EPI#n), as shown by (d) in FIG. 6. 

[0081] The PGC general information (PGCGI) may have a configuration as shown by (a) in FIG. 7. The PGC__GI 
describes: PGC contents (PGC__CNT) such as the number of programs, the number of cells and the like; a PGC trans- 
port time (PGC_TRS_TM) that describes the recording or transport time of one PGC; support information; the start 
address (PGC_PGMAP_SA) of a PGC program map (PGC.PGMAP); the start address (C_PBIT_SA) of a cell play- 
back information table (C_PBIT); the start address (C_POSIT_SA) of a cell position information table (C_POSIT); and 
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an erasure inhibition Hag (ARCHIVE Flag). 

[0082] In case of SC_GI, a cell type (C_TY1 = 01 Ob) and a temporary erase (TE) flag are described in place of the 
ARCHIVE Flag. This SC_GI may further includes: 

5 * SC_EPI_Ns which describes the number of Entry Point information contained in the SCI; 

* SOB_N which describes the number of SOBS to which the cell refers; 

* SC_S__APAT which describes the Start Application Packet Arrival Time (Start APAT) of the cell in DVD Stream 
Recording's PAT Describing Format; 

* SC_E_APAT which describes the End Application Packet Arrival Time (End APAT) of the cell in DVD Stream 
;o Recording's PAT Describing Format (The End APAT is the APAT of the last Application Packet which belongs to the 

cell.); 

* ERA* S_APAT which describes, for a "Temporarily Erased" cell containing at least one SOBU border (the TE" field 
of its C_TY is "1 0b"), the APAT of the first Application Packet of the first SOBU, the beginning of which is contained 

is * EF^E^PAT which describes, for a "Temporarily Erased" cell containing at least one SOBU border (the "TE" field 
of its CJY is "10b"), the APAT of the first Application Packet of that SOBU which contains the Application Packet 
immediately following the TE cell. 

[0083] As the flow of signals upon recording, TS packet data received by the STB are packed and recorded by a 
formatter unit. At this time, the presence/absence of each information is detected and is saved in a work RAM. The 
saved information is recorded as management information upon completion of recording. 

[0084] In the support information, as shown by (b) in FIG. 7, bit bO records a random access indicator support flag 
indicating whether or not random access is permitted, and bit b1 a unit start indicator support indicating whether or not 
start is permitted for each unit. Bit b2 records a PAT/PMT support indicating whether or not the PAT (program associa- 
tion table) and PMT (program map table) are supported, bit b3 a PCR support indicating whether or not PCR (Presen- 
tation Clock Reference) is supported, bit b4 an SCD (Splice Co.untDown) support indicating whether or not SCD is 
supported and bits b5 to b7 an identification code of the STB which recorded data. 

[0085] The identification code includes, e.g. an STB (001) of BS digital broadcast a Ver2 STB (010) of DirecTV, 
and a Ver1 STB (011) of Sky Perfect TV. 

[0086] Upon playback, pack data read out from a disc is interpreted by a distributor, and a pack that stores TS pack- 
ets is sent to a TS packet transfer unit. The TS packet transfer unit transfers only TS packets to the STB in accordance 
with a request from the STB. 

[0087] Each cell playback information (C_PBI) (or stream cell information SCI) preferably further describes support 
information, as shown in FIG. 8. ha /o at\ 

35 [0088] More specifically, as shown in FIG. 8, the cell playback information (C_PBI) records: a cell category (C_CAT) 
(or cell type CJY) in the 0th byte (relative byte position: RBP); a cell arrival time (C_ARL_TM) which describes an STC 
value or PCR upon recording the head of the cell of interest in the 1st to 4th bytes (RBP); the start address 
(C FVOBUSA) of the first VOBU in the cell in the 5th to 8th bytes (RBP); the start address (C_LVOBU_SA) of the last 
VOBU in the cell in the 9th to 12th bytes (RBP); and the end address (C_LVOBU_EA) of the last VOBU in the cell in the 

40 13th to 16th bytes (RBP). 

[0089] Also, the cell playback information describes a TS packet length indicating the length of a transport stream 
packet (TS packet) in the 17th and 18th bytes (RBP). m w *u 

[0090] Furthermore, the cell playback information (or SCI) records the number of l-pictures (REFPIC_Ns) (or the 
number of access units AU_Ns) as support information in the 19th to 22nd bytes (RBP). 

45 [0091] Moreover, the cell playback information (or SCI) records the start addresses (REFPIC_SA#1 to 
REFPIC_SA#n) and end addresses (REFPIC_EA#1 to REFPIC_EA#n) of l-pictures (or Access Unit Start Map AUSM 
and Access Unit End Map AUEM) in turn in the 23rd byte and subsequent bytes (RBP). 

[0092] REFPIC_SA# (l-picture start position) corresponds to an AUSM (access unit start map; to be described 
later) This AUSM indicates a data unit (SOBU) of a streamer object (SOB), which unit contains an access unit (AU). 
[0093] REFPIC_EA# (l-picture end position) corresponds to an AUEM (access unit end map; to be described later). 
This AUEM is a bit array having the same length as that of the AUSM. Bits in this AUEM indicate which of the SOBUs 
contains the end of a bitstream segment associated with the access units of the SOB. 

[0094] Note that the SOB and SOBU are names used in a streamer, and correspond to names VOB and VOBU 
used in DVD video (DVD_RTR). 
55 [0095] The streamer directly records an incoming bitstream. and does not concern itself with its contents (tnat is, 
the streamer does not know the recording contents). 

[0096] When a bitstream recorded by the streamer is an MPEG2 transport stream, decoding starts from an l-picture 
position. In this case, if a time search is made for a position between a given l-picture and the next l-picture (i.e., access 
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is made based on only the time stamp), since there is no l-picture at that position, the start of decoding delays until the 
next 1-picture is detected (thus the image output timing delays). 

[0097] On the other hand, when a data unit (SOBU) is used as an access unit in the streamer, since the startfend 
positions of l-picture can be determined in units of SOBUs (i.e., determined from the AUSM and AUEM), an l-picture 
position can be immediately found by a time search using an MPEG transport stream. 

[0098] That is, when the SOBU is used for the access unit, an l-picture position is immediately found by a time 
search. Therefore, decoding can be quickly started, and smooth fast forward (FF) and fast rewind (FR) can be attained. 
[0099] Note that the TS packet length is described in FIG. 8. When 188-byte TS packets are transferred in turn, no 
problem will be posed even if theTS packet length is unknown. However, some broadcast station may send a TS packet 
which has a size equal to or larger than 188 bytes to the streamer. According to the present embodiment, the packet 
length can be set in consideration of such special case. 

[01 00] Thus, after data is read out from a disc, the data packet in the pack is segmented by the TS packet length to 
obtain packets. 

[0101] When packets corresponding to the TS packet size (188 bytes) in an MPEG transport stream, the packet 
size in a DVD video (DVD_RTR) program stream, and other packet sizes (n bytes/packet) are considered as those to 
be recorded by the streamer, a generic bitstream called an application stream is used. 

[0102] As another example, a case will be exemplified below wherein support information is recorded in manage- 
ment information in the currently proposed recording/playback video format 

[01 03] FIG. 9 shows an outline of the format. Reference numeral 50 denotes a RAM video disc that allows record- 
ing, erasure, and playback. A recording area of the disc shown by (a) in FIG. 9 is defined between lead-in area 20 and 
lead-out area 21 , as shown by (b) in FIG. 9. In this area, volume & file manager information area 22 and data area 23 

are assigned. u 
[0104] Data area 23 is divided into a plurality of DVD areas 24, as shown by (c) in FIG. 9. As shown by (d) in FIG. 
9, each DVD area 24 is made up of control information 25 and video object 31 with the structure shown in FIG. 2. Fur- 
ther, as shown by (e) in FIG. 9, control information 25 is made up of VOB general information (VOBJ3I) (or stream file 
general information SF_GI) 27. and VOBU information table (or stream file information SFI) 28 which includes a number 
of pieces of VOBU information (VOBUI) (or stream object information SOBI) 29. 

[0105] VOB general information (VOB_GI) (or SF_GI) 27 has areas for recording VOBU_Ns (or SOBI_Ns). 
VOBI„End Address (or SOBU_SIZ), support information, etc., as shown by (f) in FIG. 9. 

[01 06] More specifically, VOBJ3I (or SFJ3I) records: the number of VOBUs (VOBU_Ns) (or the number of SOBIs 
(SOBIJMs)) in the 0th to 3rd bytes (RBP); the end address or the size (i.e., length) of the VOBI (or the number of sectors 
per SOBU (SOBU_SIZ)) in the 4th to 7th bytes (RBP); and support information which may be the same as that shown 
by (b) in FIG. 7 in the 8th byte (RBP). Furthermore, an erasure inhibition flag (ARCHIVE Flag) can be recorded in the 
9th byte (RBP). 

35 [0107] VOBUI (or SOBI) 29 shown by (e) in FIG. 9 can record support information shown in FIG. 10. 

[0108] More specifically, VOBUI (SOBI) 29 records; the VOBU start address in the 0th to 3rd bytes (RBP); and the 
VOBU end address or length in the 4th to 7th bytes (RBP). 

[01 09] Also. VOBUI (SOBI) describes: a system time clock (STC) or program clock reference (PCR) upon recording 
the head of the VOBU of interest as VOBU_RECTM in the 8th to 1 1th bytes (RBP); and a TS packet length indicating 
40 the length of a TS packet in the 1 2th and 13th bytes (RBP). 

[011 0] Furthermore, VOBUI (SOBI) records the number of l-pictures (REFPIC_Ns) in the 1 4th to 17th bytes (RBP). 
[011 1] Moreover. VOBUI (SOBI) records the start addresses (REFPIC_SA) and end addresses (REFPIC_EA) of I- 
pictures in turn in the 1 8th byte and the subsequent bytes (RBP). 

[0112] When a VOBU is segmented into a plurality of sets of TS packets to always locate an l-picture at the head 
45 of each set. the l-picture address is used upon segmenting the VOBU. 

[0113] REFPIC_SA# in FIG. 10 corresponds to the aforementioned AUSM (access unit start map), and 
REFPIC_EA# corresponds to the aforementioned AUEM (access unit end map). 

[0114] In this way. when an l-picture is always located at the head in a VOBU, the l-picture start address need not 
be described, and only the l-picture end address can be described. 
so [01 15] As an example for recording management data contained in the TS packet described above in the afore- 
mentioned tables, the following five pieces of information will be explained. 

[01 1 6] The first information is the random access indicator contained in the TS packet header shown by (c) in FIG. 
1 , which is activated in case of a TS packet containing first l-picture data. 

[01 1 7] With this flag, the start position of the l-picture can be specified. Two methods are available to reflect this flag 
55 on the format. 

[01 1 8] In the first method, formatting is done using this information upon segmenting data into VOBUs (or SOBUs) 
33, as shown by (a) in FIG. 11. 

[01 1 9] With this method, since the start position of each VOBU (SOBU) always matches that of an l-picture, play- 
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back in units of VOBUs (SOBUs) can be easily done. In this case, a padding packet is inserted into a VOBU (SOBU) as 
needed to always locate l-picture data at the start position in the VOBU (SOBU), as shown by (a) in FIG. 1 1 . 
[0120] As the second method, when the start positions of l-pictures are recorded in the management area, as 
shown in FIGS. 8 and 10, they can be used in a special playback mode such as FF, FR, or the like, as will be described 

later. , 
[0121] In an actual system, since an klecode end interrupt from the STB must be used, extra data is sent to the 
STB if only the l-picture start address is used, resulting in poor eff iciency. 

[0122] * Furthermore, as the second information, the unit start indicator shown by (b) in FIG. 1 is supported. 
[0123] Thus, since the l-picture end address can be specified, a special playback mode such as fast forward (FF), 
fast rewind (FR), or the like that does not read out extra data can be implemented. 

[0124] The unit start indicator can specify the start address of each l-picture. The l-picture end address is written 
as management information, as shown in FIGS. 8 and 9. 

[01 25] In this embodiment, a logical block address is used as address information. The logical block address does 
not match an actual physical address since skipping is done based on, e.g., error information and the like. Especially, 
in case of a DVD-RAM or the like, since an error occurs due to contamination such as scratches, fingerprints, and the 
like, the addresses may have a larger difference. For this reason, the logical block address is converted into a physical 
address by, e.g., a file system. 

[0126] Also, as the address information, not only the logical block address but also a method of indicating an 
address using a transfer time, converting the time information into a logical block address using a correspondence 
table, and then converting the logical block address into a physical address may be used. That is. the address informa- 
tion indicates information that can be converted into a physical address with reference to a correspondence table or the 
like or via computations. . 
[0127] The third information is a splice countdown (SCD) contained in the TS packet header shown by (d) in FIG. 
1 , by (c) in FIG. 11 , and by (a) to (c) in FIG. 13, which can specify an editable position. That is, if logical minimum units 
25 (corresponding to cells in DVD) are segmented using this unit, this information can be used in editing from each mini- 
mum unit. 

[0128] For this reason, as shown by (a) in FIGS. 12 and 13. a TS pack that includes a TS packet with SCD = 0 at 
the head of the pack is adjusted to be located at the head of a cell. By aligning cells in this manner, editing in units of 
cells can be made, as shown by (b) in FIG. 13, and seamless playback between cells can be done even after editing. 
30 as shown by (c) in FIG. 13. 

[0129] The fourth information is a method of presenting a cell or VOBU playback time, as shown in FIGS. 8 and 10. 

using PCR shown by (d) in FIG. 1. 

[01 30] Note that PCR indicates a transfer arrival reference time of a TS packet, and is not appended to all TS pack- 
ets. But since a TS stream is data to be played back in real time, PCR is highly likely to indicate the same time as the 
35 playback time. However, since the playback time is contained in a payload. it cannot be used in a recording/playback 
DVD streamer unless the data is decrypted. 

[01 31 ] For this reason, the playback time is presented using PCR information and the STC in which that time data 
is set. In this manner, the playback time can be roughly represented. However, when PCR is not supported, the play- 
back start time is set at STC = 0, and counting is then started to use an STC value at a given timing as the playback 
40 time. 

[01 32] The fifth information is PAT and PMT packets shown by (b) in FIG. 1 1 and by (a) to (c) in FIG. 1 2, and these 
packets record the PIDs of data of a program which is to be played back. These packets are inserted at intervals of sev- 
eral 100 ms to several seconds; when a program is played back from a midway position, playback starts based on this 
data. 

45 [01 33] For this reason, these packets can be used to segment data, as shown by (b) in FIG. 1 1 and by (a) to (c) in 

FIG. 12. ■ 
[01 34] Note that the PAT and PMT packets can be used in the following four segmentation methods in correspond- 
ence with the DVD video format. 

[0135] First, as shown by (b) in FIG. 11, when the head of a VOBU (or SOBU) is aligned to that of a PAT packet, 
so playback from a midway position in units of VOBUs (SOBUs) can be made. However, since video data after the PAT 
packet does not always start from an l-picture, a slight time lag is produced until an l-picture is found. For this reason, 
segmentation at the positions of l-pictures is preferable for VOBUs (SOBUs). 

[0136] Second, as shown by (a) in FIG. 12, the head of a cell is aligned to that of a PAT packet to be used as the 
cell segmentation position. However, since PAT packets appear at intervals of several 100 ms to several seconds, cell 
55 segmentation positions are set every some PAT packets. However, in this method, since an edit point is not used as a 
reference point, ii editing is done, continuity is disrupted, and seamless playback cannot be guaranteed. For this rea- 
son, cell segmentation based on SCD is preferable. 

[0137] Third, as shown by (b) in FIG. 12, a program may be segmented using PAT packets. With this method, PG 
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jump, PG skip, and the like can be implemented. However, since PAT packets appear at intervals of several 100 ms to 
several seconds, program segmentation positions are set every several ten to several hundred PAT packets. 
[0138] Fourth, as shown by (c) in FIG. 12, a PGC may be segmented using PAT packets. With this method, PGC 
jump, PGC skip, and the like can be implemented. However, since PAT packets appear at intervals of several 100 ms to 
several seconds, program segmentation positions are set every several hundred to several thousand PAT packets. 
[0139] The identification code of the STB indicates the type of digital broadcast that the STB connected can 
receive. With this code, the STB connected is checked upon playback, and the same STB used upon recording can be 
selected to play back data. Furthermore, this code can change operation that pertains to playback time presentation. 
[0140] When the STB supports a command for outputting a playback time to a recorder, the playback time is peri- 
odically read from the STB and is presented. This value is most accurate as the playback time. 
[0141] The system arrangement of a satellite broadcast compatible DVD recorder/player will be explained below 
with reference to FIG. 14. 

[0142] Referring to FIG. 14, reference numeral 50 denotes a RAM disc, which is driven by disc drive 51 that 
exchanges data with data processor (D-PRO) 52. Temporary memory 53 for temporarily saving data is connected to 
data processor 52. 

[0143] The recorder/player of FIG. 14 can record and playback an MPEG bitstream and/or a normal video signal. 
These bitstream and video signal may be recorded independently, or mixed with one another. 
[0144] Decoder unit 59 in the system shown in FIG. 14 includes distributor 60 having a memory, which receives 
playback data transferred from data processor 52. 

[0145] The playback data is demultiplexed by distributor 60 into video data, sub-picture data, and audio data 
(packet data). The video data is transferred to video decoder 61 having reduced-scale image (thumbnail picture) gen- 
erator 62, and the sub-picture data and audio data are respectively transferred to sub-picture decoder 63 and audio 
decoder 64. 

[0146] Digital video and sub-picture signals respectively decoded by video decoder 61 and sub-picture decoder 63 
are synthesized by video processor (V-PRO) 65, and the synthesized signal is supplied to video mixing unit 66. Video 
mixing unit 66 is connected to frame memory 73 for temporarily storing a digital video signal in units of frames, and 
externally supplied text data or the like is mixed into a video frame. Then, the digital video signal is supplied to D/A con- 
verter 67, and a D/A-converted video signal is output to TV monitor 68. The digital video signal can be externally output 
via interface 69. 

[0147] A digital audio signal from audio decoder 64 is supplied to D/A converter 70, and a D/A-converted audio sig- 
nal is output to loudspeaker 72. The digital audio signal can also be externally output via interface 71 . 
[0148] Reduced-scale image (thumbnail picture) generator 62 of video decoder 61 generates a video signal of a 
reduced-scale image of transferred video data on the basis of a reduction ON command from main MPU 80, and sup- 
plies it to video processor 65 to display the reduced-scale image on TV monitor 68. Key input unit 103 having keys for 
instructing external commands such as playback (PLAY), stop (STP), a marker that appends a mark associated with a 
recording position, and the like, and display unit 104 are connected to main MPU 80. 

[0149] Encoder unit 79 in the system shown in FIG. 14 can receive an AV input from external AV apparatus 81 or 
TV tuner 82, and can also receive digital broadcast data from STB 83. A satellite broadcast antenna for receiving digital 
broadcast data is connected to STB 83. 

[0150] An AV signal from external AV apparatus 81 or TV tuner 82 is converted into a digital signal by A/D converter 
84. In this case, a digital audio signal is supplied to audio encoder 86 and a digital video signal to video encoder 87 via 
selector 85, and these signals are MPEG-encoded. 

[01 51 ] When caption information such as character information or the like is output from TV tuner 82, it is supplied 
to sub-picture encoder 88 and is runtength-encoded. 

[0152] Data encoded by encoders 86, 87, and 88 are supplied to formatter 90, to which buffer memory 91 is con- 
nected, are stored in video, audio, and sub-picture packets appended with packet headers by formatter 90. and these 
packets are converted into pack structures by appending pack headers. 

[01 53] These packs are grouped together in units of VOBUs (SOBUs), as shown by (d) in FIG. 2, and a number of 
VOBUs (SOBUs) are grouped into a cell. Then, a set of cells are grouped into video object VOB (SOB), and a video 
object set is formed as needed. 

[0154] During the formatting process, formatter 90 generates management information with reference to segmen- 
tation information generated by TV tuner 82. For example, PGC information is generated with reference to segmenta- 
tion information. 

[0155] The generated management information and pack data are sent to data processor 52, which stores the gen- 
erated management information in a management data table generated by and supplied from a management data gen- 
erator 80B of main MPU 80. Then, the management and pack data are recorded on optical disc 50 via disc drive 51 . 
[0156] STB 83 directly supplies an MPEG2 transport stream corresponding to the selected program, i.e., title, to 
formatter 90. The stream is formatted, as shown in FIG. 1 , and management information is generated. Data processor 



10 



. <EP 1021046A2J_> 



10 



EP 1 021 048 A2 

52 stores the management data in a predetermined management data table, and the management data table and 
transport packets are similarly recorded on optical disc 50 via disc drive 51 . 

[01 57] STB 83 incorporates a decoder, which decodes AV data in TS packets to convert it into audio and video sig- 
nals. The audio and video signals are respectively supplied to loudspeaker 72 and TV monitor 68 via D/A converters 70 
and 67. 

[01 58] TS packs 34 supplied to optical disc 50 are supplied to distributor 60 of decoder unit 59 via data processor 
52 and disc drive 51. Distributor 60 detects with reference to the stream and substream IDs that packet data in these 
packs are TS packet data, and distributes those TS packets to TS packet transfer unit 100. 
[0159] TS packet transfer unit 100 supplies TS packets 38 to STB 83 at predetermined transfer timings. Data in 
each TS packet is decoded by STB 83, and decoded audio and video signals are respectively supplied to loudspeaker 
72 and TV monitor 68 via D/A converters 70 and 67. 
[0160] in the aforementioned recording/payback operation, decoder unit 59 and encoder unit 79 execute data 
transfer and the like under the control of system time clocks 102. 

[01 61 ] The recording and playback processes will be explained below with reference to FIGS. 1 5 to 23. 
is [0162] A data process upon recording will be described first with reference to the flow charts shown in FIGS. 1 5. 
16, and 17. 

[0163] When main MPU 80 receives a recording command from key input unit 103 in step S10, the recording proc- 
ess starts. 

[0164] Disc drive 51 loads management data from optical disc 50 in step S11 , and it is checked in step S12 if a free 
20 space is available. If no free space is available, a message indicating no free space is displayed on display unit 103 in 
step S13, and the process ends in step S14. 

[0165] On the other hand, if a free space is available, a write area is determined in an area corresponding to the 
free space, i.e., a write address is determined in step S15. In order to write recording data in the determined area, that 
address is written in the management area, and the write start address of video data is set in disc drive 51 to prepare 
for data recording. In step S16, a command for reading out EPG (electronic program guide) information from STB 83 is 

[W66]" In response to a request from MPU 80, STB 82 prepares the latest EPG at that time. That is, STB 82 
receives the latest EPG and saves it in a work memory. The EPG data which has been received or saved in the work 
memory in the STB 83 is sent back to MPU 80. 

[01 67] MPU 80 displays that EPG data in step S1 7 to make the user select a program to be recorded. After that, if 
the program to be recorded is determined, MPU 80 issues a command for outputting support information to STB 83, 
and receives support information from STB 83, as shown in step S18. At this time. MPU 80 also receives an STB iden- 
tification code from STB 83 together with support information. The support information is detected by support manage- 
ment information detector 80C in MPU 80. 
35 [0168] If no support information is available in STB 83. the presence/absence of support information is checked 
during information, and detected information is used instead. MPU 80 designates a target program to be recorded in 
STB 83, and make STB 83 start reception of the program. 

[0169] MPU 80 issues an instruction for writing management information in the management area on optical disc 
50 in step S19. That is, VTS is registered in VMGI to generate VTSI as a management data table for a video title set, 
40 and support information is written in VTSI. Or, STRJ/MGI (FIG. 6) is prepared in step S1 9. 

[0170] In DVD_RTR (a system for internally converting analog video data into MPEG data and recording the MPEG 
data in real time), the roles of VMGI and VTSI are integrated in RTR video manager information (RTR_VMGI). Hence, 
when a DVD_RTR recorder is used as a streamer, VMGI and VTSI (or STR_VMGI) may be read as RTR.VMGI as 
needed. 

45 [0171] MPU 80 resets the time of STC 102 as an initialization process for recording in step S20. Note that STC 102 
is a system timer, and recording and playback are executed with reference to the value generated by STC 102. Data of 
VMG and VTS files are written in a file system, and required information is written in VMGI and VTSI. 
[0172] At this time, if support information has been detected, the detected support information is written. Further- 
more, the respective units undergo recording setups. At this time, data segmentation is set in the formatter, as has been 

so explained above with reference to FIGS. 1 1 to 1 3, and the formatter is set to receive TS packets. 

[0173] Upon starting recording, the respective units undergo recording start setups in step S21 in FIG. 16. More 
specifically, a recording start command is supplied to formatter 90, which starts recording and formatting of recording 

data. . ; 

[0174] When recording has been started, MPU 80 checks in step S22 if an update input of segmentation mforma- 
55 tion. i.e.. data grouping information that has been explained with reference to FIGS. 1 1 to 1 3. is detected. If such input 
is detected, that segmentation information is saved in work RAM 80A of MPU 80 in step S23. 
[0175] After the segmentation information is saved, or if segmentation information is not updated, it is checked in 
step S24-1 if a recording end key input is detected. If the recording end key input is detected, a recording end process 
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is executed in step S28. If no recording end key input is detected, the size of the free area in optical disc 50 is checked 
in step S24-2 to compute the remaining space size. 

[0176] It is checked in step S25 if the remaining space size has become equal to or smaller than a predetermined 
value. If the remaining space size is not equal to or smaller than the predetermined value, the flow repeats step S25 to 
periodically check the remaining space size. If the remaining space size has become equal to or smaller than the pre- 
determined value, a process for a small remaining space size is done in step S26. 

[0177] After that, it is checked in step S27 if no recordable space is available, ff a sufficient recordable space is 
available, the f low returns to step S22 to repeat steps S22 to S26. 

[0178] If no recordable space is available, a recording end process is done in step S28. In this recording end proc- 
ess, segmentation information for the remaining data is received from formatter 90, and is added to work RAM 80a. 
These data are recorded in management data (VMGI and VTSI; or RTR_VMGI; or STR_VMGI), and information for 
recorded data is recorded in the file system. After that, recording ends in step S29. 

[0179] The flow of a video signal in the recording operation in the system shown in FIG. 14 will be described in 
detail below. 

[0180] TS packets input from STB 83 are input to the formatter. The time elapsed from the transfer start timing is 
read from the STC value, and is saved in buffer RAM 91 as management information. This information is sent to MPU 
80 together with segmentation information, and is recorded in management information. As segmentation information, 
VOBU (or SOBU) segmentation information, cell segmentation information, program segmentation information, and 
PGC segmentation information are generated, and are periodically sent to MPU 80. 

[0181] Note that the VOBU (SOBU) segmentation information includes the VOBU (SOBU) start address, VOBU 
(SOBU) playback time, and (-picture start and end addresses. In the (-picture start address, the address of a pack that 
records a TS packet including an active random access indicator is set. 

[0182] As for the l-picture end address, since a TS packet that stores video data immediately before a TS packet 
including an active unit start indicator after the random access indicator is active is an l-picture end packet, the address 
of a pack which records that TS packet is set in the l-picture end address. 

[0183] As the VOBU (SOBU) playback time, the time required from the start to end of transfer of a VOBU (SOBU) 
is used instead. 

[0184] Formatter 90 temporarily saves TS packet data in buffer memory 91. Then, the formatter packs the TS 
packet data input to obtain packed data, formats the packed data to obtain a pack sequence shown by (e) in FIG. 2, and 
inputs the pack sequence to D-PRO 52. 

[0185] D-PRO 52 groups 16 packs together to obtain an ECC group, appends error correction data thereto, and 
sends the ECC group to disc drive 51 . When disc drive 51 is not ready to record, D-PRO 52 transfers the ECC group 
to temporary memory 53 and waits until disc drive 51 is ready to record. When disc drive 51 is ready, D-PRO 52 starts 
recording. As temporary memory 53, a large-capacity memory is assumed since it must hold recording data for several 
min or more by high-speed access. 

[01 86] Note that a microcomputer can make read/write access to D-P RO 52 via a microcomputer bus to read/write 
the file management area or the like. 

[0187] Upon completion of recording, an erasure inhibition flag (protect or archive flag) is cleared to permit erasure. 
That is, at the beginning of recording, erasure is allowed. 

[0188] A data process upon playback will be explained below with reference to FIGS. 1 7 and 18. 

[01 89] Upon receiving a playback command, MPU 80 starts a playback process in step S30. Disc drive 51 searches 

disc 50 to check for any defects in step S31 . 

[0190] If any defects on disc 50 are found upon checking disc 50, an error process is executed in step S32, and 
playback comes to an end in step S33. 

[0191] If no problem is found on disc 50, STB 83 connected is checked in step S34 to fetch its identification code. 
After that, disc drive 51 searches the management area on disc 50 to load its management information (VMGI or STRI 
including STR_VMGI) via D-PRO 52 in step S35, thus allowing the user to select a title set (one or more PGCs) to be 
played back. 

[01 92] When the user determines the title set (PGCs) to be played back and its address is determined in step S36, 
MPU 80 sends a read command of the determined address to disc drive 51 . Hence, VTSI (or STR_VMGf) of the deter- 
mined title set (PGCs) is loaded and PGCI (or play list search pointers) in the loaded VTSI (or STR_VMGI) is saved in 
work RAM 80A in step S37. 

[0193] In step S38, all titles or PGCs (or programs (PGs)) corresponding to STB 83 connected in the selected title 
set are displayed. Based on this display, the user determines the title or PGC (or program) to be played back in step 
S39. 

[0194] Subsequently, in step S40 support information in the management information shown in FIG. 7 or 9 is read 
out, and the individual units are set based on the support information. That is, it is checked in step S41 if the random- 
access indicator is supported. If the random access indicator is supported, a flag that permits FF and FR special play- 
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back modes based on l-picture is set in step S42. 

[01 95] If the random access indicator is not supported, rt is checked in step S43 if PAT is supported. If PAT is sup- 
ported, a flag that permits FF and FR special playback modes based on PAT is set in step S44. If PAT is not supported 
either, a flag that inhibits FF and FR special playback modes is set in step S45. 

[0196] Upon completion of setups based on the support information, program and cell numbers from which play- 
back starts are determined in step S46. MPU 80 sends a playback command of TS packets to STB 83 via an internal 
bus. MPU 80 also initially sets up distributor 60 to send TS packets to STB 83, and sets V mixing unit 66 to allow a dis- 
play process of a video signal sent from STB 83 (step S47 in FIG. 18). 

[0197] Disc drive 51 reads out sector data from disc 50 in accordance with a command sent from MPU 80, i.e., the 
determined program and cell numbers. D-PRO 52 corrects errors of readout data, and outputs corrected data to 
decoder unit 59 as pack data. . 
[01 98] In decoder unit 59, distributor 60 determines based on the stream and substream IDs of the pack data that 
incoming data contains TS packets, and sends TS packets to TS packet transfer unit 100. The TS packets are then 
transferred to STB 83 (step S47). . 
[01 99] STB 83 then decodes incoming TS packets. In case of normal broadcast reception, incoming data is directly 
written But in case of data exchange via the internal bus, data transfer is done using REC and ACK signals as follows. 
That is, when a buffer consumed by STB 83 is empty, an REC signal is activated. When distributor 60 is ready to trans- 
fer data, an ACK signal is activated every time data is sent onto the bus. In this manner, data is transferred in response 
to a data transfer request from STB 83. 

[0200) The sent TS packet data are played back by STB 83. and video data is converted into a TV signal via V mix- 
ing unit 66 and is displayed on TV monitor 68. Also, an audio signal is sent to D/A converter 70 to be converted into an 
analog audio signal, and the converted signal is played back from loudspeaker 72. 

[0201 ] During playback. PCR data is periodically set in the STC, and the contents of the STC are displayed as a 
playback time When STB 83 can transfer a playback time, playback time data is periodically transferred and displayed. 
If STB 83 can display a playback time based on PTS in video data, that playback time is displayed. 
[0202] The playback process is done in units of cells, as shown in step S48 in FIG. 18. MPU 80 always checks if 
disc drive 51 has stopped due to errors or the like after the cell playback process (step S49). If the drive has stopped, 
the playback operation comes to an end in step S50. 

[0203] K disc drive 51 is in operation, it is always checked if the current cell is the last cell. If the current cell is not 
the last cell (step S51). the cell number is counted up in step S52, and the flow returns to the cell playback process in 
step S48 

[0204] If the last cell has been reached in step S51 , rt is checked in step S53 if playback is to end. If playback is not 

to end. the flow returns to step S48 to start playback of a cell of another program (or another play list) or PGC. 

[0205]' If the end of playback is determined in step S53, a playback end process is done in step S54, and the play- 
35 back operation comes to an end in step S55. 

[0206] The cell playback process shown in FIG. 18 will be explained in detail below with reference to FIG. 19. 

[0207] Initially, when the cell playback process corresponding to step S48 in FIG. 18 starts in step S60 in FIG. 19. 

it is checked in step S61 if a cell playback process start request is detected. If no cell playback process request is 

detected, it is checked in step S62 whether VOBUs (or SOBUs) are continuous. 
40 [0208] If VOBUs (SOBUs) are continuous, it is checked in step S65 if an FF key is input 

[0209] If VOBUs (SOBUs) are not continuous, a playback start address (logical block number LBN) is determined 

with reference to PGCI (or SOBI in FIG. 1 0) in step S63. in step S64, a data read command is sent to disc drive 51 using 

this address, and disc drive 51 starts a search. 

[021 0] After that, cell playback starts from the playback start address, and it is also checked in step S65 during play- 

45 back rf the FF playback key is input. 

[021 1 ] If it is determined in step S65 that the FF playback key is input, it is confirmed in step S66 if FF playback is 
permitted If FF playback is not permitted, a message "no FF playback permitted by broadcast station" is displayed in 
step S67, and the flow advances to step S71 . Note that FF operation is inhibited and the message "no FF playback per- 
mitted by broadcast station* is displayed when support information neither specifies l-picture nor supports PAT. 

so [021 2] If FF playback is permitted, an FF process is executed in step S68. It is checked (step S69) if disc drive 51 
has stopped due to errors or the like during the FF process, and if disc drive 51 has stopped, the FF process and play- 
back process end in step S70. 

[0213] If it is determined in step S65 that the FF playback key is not input, or if an FF non-permission message is 
displayed in step S67. or when drive 51 is not stopped in step S69. then it is checked in step S71 whethenSTB 83 is of 
55 a type that outputs a playback time. IICTDW 
[021 4] If STB 83 outputs a playback time, the playback time output from STB 83 is displayed in step S72. it oi B oo 
does not output any playback time, it is confirmed with reference to support information in step S73 whether manage- 
ment data of an incoming TS packet includes PCR that describes time information. 
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[021 5] If PCR is supported, the PCR value in management data of that TS packet is displayed in step S75, and the 
flow advances to step S76. If PCR is not supported, the measured by STC 102 is displayed (step S74), and the flow 
advances to step S76. 

[0216] It is confirmed in step S76 if the current cell is the last cell. If the current cell is not the last cell, the flow 
returns to step S65 to execute steps S65 to S75 again. 

[0217] On the other hand, if the current cell is the last cell, the control waits for the end of playback of VOBUs (or 
SOBUs) in that cell in step S77. Upon completion of VOBU (or SOBU) playback, the flow returns to the aforementioned 
step S54 of FIG. 18, as shown in step S78. 

[0218] Special playback modes will be explained below with reference to FIGS. 20 to 23. In this example of special 
playback mode, FF playback will be explained. But the same applies to FR playback, and a detailed description thereof 
will be omitted. 

[021 9] In the FF playback process in step S68, the flows shown in FIGS. 20 and 21 are executed. 
[0220] That is, when the FF process starts in step S80, an only l-picture playback command is sent to STB 83 (step 
S81). It is confirmed with reference to support information in step S82 if a TS packet supports the random access indi- 
cator. If the TS packet does not support the random access indicator, an FF process using PAT is started in step S84. 
The FF process using PAT will be explained later with reference to FIG. 23. 

[0221 ] If the TS packet supports the random access indicator, it is confirmed in step S83 if a VOBU (SOBU) which 
is currently being transferred corresponds to the last VOBU (SOBU) in the cell. If the current VOBU (SOBU) is the last 
VOBU (SOBU), the l-picture start address in the next VOBU (SOBU) is read out in step S86, and the flow advances to 
step S87. On the other hand, if the current VOBU (SOBU) does not correspond to the last VOBU (SOBU), the l-picture 
start address, two VOBUs (SOBUs) ahead of the current VOBU (SOBU), is read out (step S85), and the flow advances 
to step S87. 

[0222] It is checked in step S87 if the unit start indicator is supported. 

[0223] If the unit start indicator is supported (YES in step S87), a transfer interrupt flag is cleared and the next I- 
picture end address is read out in step S91. Then, a read command designated with the start and end addresses of I- 
picture is sent to disc drive 51 in step S92 t thus reading out l-picture data based on the l-picture start and l-picture end 
addresses. 

[0224] In step S93, the control waits for a data transfer end interrupt, i.e., an interrupt from disc drive 51 to confirm 
if transfer of that l-picture data has ended. 

[0225] If transfer has ended, the flow returns to step S91 to execute steps S91 and S92 again so as to playback the 
next l-picture. If transfer of the l-picture data has not ended, it is confirmed in step S94 if a STOP or PLAY key is 
pressed. 

[0226] If neither of these keys are pressed, the flow returns to step S93 to wait for transfer of l-picture data. If either 
key is pressed, the flow advances to step S95 shown in FIG. 21 . 

[0227] If it is determined in step S87 that the unit start indicator is not supported (NO in step S87), an l-picture play- 
back interrupt flag is cleared and a read command designated with the start address of l-picture and continuous read 
is issued to disc drive 51 in step S88. 

[0228] After that, the control waits for an l-picture decode end interrupt, i.e., an interrupt from STB 83, and if an 
interrupt is detected, the flow returns to step S88 to execute steps S88 and S89 again. 

[0229] If no interrupt is detected, it is confirmed in step S90 if a STOP or PLAY key has been pressed. If neither of 
these keys are pressed, the flow returns to step S89 to wait for an interrupt from STB 83. On the other hand, if it is deter- 
mined in step S90 that either key is pressed, the flow advances to step S95 shown in FIG. 21 . 
[0230] The interrupt process (step S89 in FIG. 20) is executed, as shown in FIG. 22. That is, when the interrupt 
process is started in step S1 20, a factor of interruption is checked in step S1 21 . 

[0231 ] If this factor indicates a transfer end interrupt process from disc drive 51 , a transfer end interrupt flag is set 
in step S122; if the factor indicates an l-picture playback interrupt process, an l-picture playback interrupt flag is set; or 
if the factor indicates a timer interrupt process, and if STB 83 can output a playback time, the playback time is received 
from STB 83 and is set in a work RAM. After such setups, the corresponding step is executed. 
[0232] If it is determined in step S95 of FIG. 21 that the input key is the STOP key, a stop command is set in step 
S96, and the playback end process (step S54 in FIG. 18) is executed in step S97, thus ending playback. 
[0233] On the other hand, if it is determined in step S95 that the PLAY key has been pressed, a read command pro- 
vided at the l-picture start address of the next VOBU (SOBU) is sent to disc drive 51 in step S98, and a data read is 
started based on that address in step S99. thus reading out data in turn. After that, the f tow of process returns to step 
S48 in FIG. 18, as shown in step S100, and the FF playback process ends. 

[0234] As for FR playback, only the l-picture position to be read out is opposite to FF, and the flows shown in FIGS. 
20 and 21 can be used. When the TS packet structure has a packet access pointer, the following process is done in the 
special playback mode. 

[0235] When VOBUs (SOBUs) are grouped in units of l-pictures, since TS packets are aligned in units of VOBUs 



14 



. <EP 1O2104BA2J_> 



EP 1 021 048 A2 

(SOBUs), no packet access pointer will be required. However, if VOBUs (SOBUs) are not grouped in units of l-pictures, 
a problem will be posed upon executing playback using the random access pointer. 

[0236] More specifically, when a pack is to be read out based on the start address of l-picture, since l-picture is not 
always located at the head of a VOBU (SOBU), the start position of the data area of the pack is unlikely to match the 
5 segmentation (or split) start position of a TS packet. In such case, the packet access pointer (e.g., 0x2e as shown by 
(d) in FIG. 3) determines the segmentation (split) start position of the TS packet 

[02371 The FF process using PAT (program association table) in step S84 shown in FIG. 20 is done, as shown in 
FIG. 23. ' 

[0238] When the FF process using PAT is started in step S1 01 , it is checked in step S1 02 if the transferred VOBU 
w (SOBU) is the last VOBU (SOBU) in a cell. If the transferred VOBU (SOBU) is the last VOBU (SOBU) , the start address 
of a VOBU (SOBU) at the head of the next cell is read out in step S104. On the other hand, if the transferred VOBU 
(SOBU) is not the last VOBU (SOBU), the start address, two VOBUs (SOBUs) ahead of the current VOBU (SOBU), is 
read out in step S1 03. 

[0239] In step S105. an l-picture playback interrupt flag is cleared, a read command with the start and end 
is addresses of a VOBU (SOBU) is sent to disc drive 51 , and the control waits for an l-picture decode end interrupt, i.e.. 
an interrupt from the STB. 

[0240] H an l-picture playback interrupt is detected in step S1 06, the flow returns to step S105. On the other hand, 
if no l-picture playback interrupt is detected, and transfer has ended, it is checked in step S107 whether the STOP or 
PLAY key has been operated. If no key input is detected, the flow returns to step S1 06. 
20 [0241 ] tt is confirmed in step S108 whether or not the input key is the STOP key. If the STOP key has been entered, 
a stop command is supplied to disc drive 51 in step S109, and a playback end process (step S54 in FIG. 18) is done in 
step S110. 

[0242] On the other hand, H the input key is the PLAY key, a read command with the l-picture start address of the 
next VOBU (SOBU) is sent to disc drive 51 in step S1 1 1 , and a data read is started based on that address in step S1 1 2. 
25 thus reading out data in turn. After that, the flow returns to step S48 in FIG. 18. as shown in step S1 13, thus ending the 
FF playback process. 

[0243] In the following, stream data according to an embodiment of the present invention will be explained. 
[0244] FIG. 24 shows a data structure of the stream data (corresponding to the MPEG2 transport stream of FIG. 1). 
[0245] The stream data is recorded as a group of stream objects (SOB) for each content of video information in the 
so stream data. One SOB of them is shown by (f) in FIG. 24. and is represented by SOB#A 298. 

[0246] When such stream data is recorded on a DVD-RAM disc, the recording will be performed in minimum units 
of sectors each having 2048 bytes. A group of 16 sectors constitutes an ECC block in which performed are interleaving 
(re-ordering of arrangement of data pieces) and adding of error correction codes. 

[0247] In the embodiment, a unit of one or more ECC blocks is used to constitute a stream block. Recording and/or 

35 partial erasing of stream information will be performed in unit of the stream block. In the embodiment, the number of 
ECC blocks constituting the stream block depends on a transport rate of the stream data to be transmitted. 
[0248] In digital broadcasting, one transponder receives packets of a plurality of programs which are time-divided. 
For instance, when a second program is to be recorded on a information storage medium, STB unit 83 of FIG. 14 
extracts the transport packets (TS packets in FIG. 3) of the second program only. At that time, in STB unit 83, the time 

40 information of reception of respective transport packets is added as a timestamp (ATS in FIG. 3). 

[0249] Thereafter, when data is transmitted to formatter unit 90 of FIG. 14 according to IEEE1394, pairs of the 
timestamps (ATS) and the transport packets (TS packets) are finely segmented and the segmented ones are transmit- 
ted. In formatter unit 90, the stream data transmitted according to IEEE1394 is changed to the format as shown by (a) 
in FIG. 24, and recorded on information storage medium 50 of FIG. 14. 

45 [0250] ' More specifically, a pack header and a PES header are arranged at the leading portion of each sector (cf. 
(c) in FIG. 24, FIG. 39), wherein the pack header includes information such as system clock information. In each of the 
stream blocks, and only for the leading one of the sectors therein, stream block header 1 1 is recorded immediately after 
the PES header. For other sectors following the leading sector, no stream block header is recorded, but sector headers 
12, 13 are recorded immediately after the PES header. 

so [0251 ] The timestamps (ATS) and transport packets as shown by (a) in FIG. 24 are sequentially inserted in data 
areas 21-24 as shown by (c) and (i) in FIG. 24. 

[0252] Note that in the example shown by (b) in FIG. 24, one transport packet d is recorded across two sectors 

(from No. 0 to No. 1 ). ■ ^ ♦ 

[0253] When one transport packet is recorded across a plurality of sectors, it is possible to record a large pacKet 
55 having a size larger than the one sector size. 

[0254] The digital broadcasting utilizes a multiply-segmented scheme applicable to mufti-programs, or utilizes a 

transport stream, wherein the size of one transport packet is relatively small (1 88 bytes or 1 83 bytes). 

[0255] Meanwhile, as in the example of data structure of FIG. 24, one sector has a 2048-byte size as mentioned 
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earlier. Thus, ©/en if the sizes of respective headers are subtracted from the 2048 bytes sector size, about ten transport 
packets can be recorded in one of data areas 21-24. 

[0256] In contrast, in a digital communication network as ISDN, a long packet having 4094 bytes may be transmit- 
ted. 

[0257] According to the present invention, one packet can be continuously recorded across a plurality of data areas. 
By so doing, it is possible to achieve not only recording of transport packets in one data area of digital broadcasting, but 
also recording of a large-size packet as the long packet of ISDN. 

[0258] In other words, any type of packets, such as a transport packet of digital broadcasting or a long packet of 
digital communication, can be recorded in the stream Hock without fragments, independently of the packet size. 
[0259] When a space remains in the stream block, padding data (that can be recognized as information of an unre- 
corded area) is recorded in the remaining space. More specifically, as shown by (b) in FIG. 24, end code 31 is placed 
after the last transport packet f in stream block #1 , so that the remaining area is set as padding area 36. 
[0260] FIG. 25 shows the internal structure of the stream block header as shown in FIG. 24. 
[0261] In (d) of FIG. 24, a value larger than the size of data area 22 of sector No. 1 is set as the value of the first 
access point of sector No. 1. Then, it is indicated that the position of a timestamp exists in the subsequent sectors, 
wherein that timestamp corresponds to the subsequent packet next to the packet recorded in sector No. 1 . 
[0262] Information similar to said sector data header is also recorded in sector data header information 613 (FIG. 
25) of stream block header 1 1 , 

[0263] Information pieces of stream block information 61 2 in which recorded is information relating to whole stream 
block are: 

* record time 622 (date/time information of recording on the information storage medium); 
' transport packet attribute 623 (attribute information relating the transport packet); 

stream block size 624 (data size of corresponding stream block (described by the number of ECC blocks)); 

* stream block time difference 625 (time range information in the corresponding stream block); 

The above stream block time difference can be calculated as follows, when (b) in FIG. 24 is exemplified: 

[stream block time difference] = [the value of first timestamp in stream block #2] - (the value of timestamp a] 

Formatter unit 90 in FIG. 14 converts the stream data, which is input with the form of (a) in FIG. 24, into the form of 
(c) or (i) of FIG. 24, and the converted data is subsequently input to D-PRO unit 52. 

[0264] In D-PRO unit 52, input data is grouped with 16 sectors to form an ECC block, and the ECC block is sent to 
disc drive unit 51 . 

[0265] Note that the sent ECC block data is sent to temporal storage unit 53 to temporarily store it, when disc drive 
unit 51 is not yet in a recordable condition, and the system waits for the preparation of recording. When disc drive unit 
51 is in the recordable condition, the data stored in temporal storage unit 53 is read out to start the recording on the 
information storage medium. 

[0266] The flow of signals in the stream data recording/ reproducing apparatus according to an embodiment of the 
present invention will be as follows. 

[0267] As mentioned, the structure of stream data to be recorded on information storage medium 50 is changed by 
formatter unit 90 to the data structure as shown by (c), (i) of FIG. 24. 

[0268] In an embodiment of the present invention, assume that the same transport packet is prohibited from being 
recorded across different stream blocks. Under this assumption, when the timestamp and packet data both temporarily 
stored in a buffer memory are segmented for each stream block, it is necessary to completely include a pair of the 
timestamp and transport packet within one stream block. 

[0269] On the other hand, according to an embodiment of the present invention, the same transport packet can be 
recorded across different sectors (e.g., No. 0 and No. 1 shown by (d) in FIG. 24). In this case, data segmentation for 
each sector will be mechanically performed based on a prescribed size assigned to each of data areas 21-24. 
[0270] In digital broadcasting, video information is compressed according to MPEG2 specification, and the result- 
ant I-. B-, and P-picture information is recorded in different transport packets. Then, these transport packets are trans- 
mitted. 

[0271 ] The transport packet is constituted by a transport packet header and payload. 

[0272] In the first one of transport packets wherein l-picture information is recorded, a flag of the random access 
indicator (corresponding to AUSM of (c) in FIG. 1) is set to "1". Meanwhile, in the other first one of transport packets 
wherein B- or P-picture information is recorded, another flag of the payload unit start indicator is set to "1". 
[0273] Information of the random access indicator (AUSM) and information of the payload unit start indicator are 
used to prepare l-picture mapping table 641 (table of an access unit start map) and B, P-picture start position mapping 
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table 642 (table of an access unit end map). These tables are shown by (e) in FIG. 25. 

[0274] Each mapping table in transport packet mapping table 632 shown by (d) in FIG. 25 is configured to a bitmap 
format. 

[0275] For instance, when "n" transport packets are recorded in one stream block, the value of number of transport 
5 packet 631 shown by (d) in FIG. 25 is set to V. 

[0276] In this case, each mapping table in (e) of FIG. 25 is formed of "n-bif data, and bits of the "n-bit n data are 
respectively assigned to the transport packets in the stream block. These transport packets are sequentially arranged 
from the front of the stream block. 

[0277] FIG. 26 shows an internal structure of the sector data header shown in FIG. 24. 
w [0278] Sector data headers 12 and 13 as shown by (c) and (i) in FIG. 24 represent information of data arrange- 
ments in data areas 2 1 -24. 

[0279] As shown in FIG. 26, each of these sector data headers is formed of first access point 651 and transport 
packet connection flag 652. 

[0280] As shown by (b) in FIG. 24, transport packet d Is recorded across two sectors. In this case, the last times- 
is tamp in these sectors is set to "1 When the recording of the transport packet is extended to the next sector, transport 
packet connection flag 652 is set to "1 

[0281] In the example shown by (b) in FIG. 24, the address in data area 22 at the leading position of timestamp is 
recorded (expressed by bit unit) in first access point 651 of (b) in FIG. 26. Here, the leading position of timestamp 
appears next to the latter sector of transport packet d which is recorded across former and latter sectors. 
20 [0282] According to an embodiment of the present invention, a value larger than the size of data areas 21-24 can 
be used as the value of first access point 651 . By so doing, it is possible to specify the leading position of timestamp of 
a large packet which has a size larger than the sector size. 

[0283] For instance, in the data structure of (d) in FIG. 24, assume that one packet is recorded across sector No. 0 
and sector No. 1 , that the timestamp of this one packet is recorded at the first position in data area 21 of sector No. 0, 
25 and that the timestamp of the next packet is located at the T-th bit position in the data area of sector No. 2. 

[0284] Under the above assumption, the value of the first access point for sector No. 0 is n 0". the value of the first 
access point for sector No. 1 is "size of data area 22 of sector No. 1 plus T\ and the value of the first access point for 

sector No. 2 is T\ . 

[0285] According to an embodiment of the present invention, reproduction or playback will be started basically from 
30 the start portion of the stream block. However, in a rare case, reproduction could be started from the leading portion of 

an ECC block which belongs to the second or subsequent one of ECC blocks in the stream block. 

[0286] As in the case of FIG. 24, if the same transport packet d is recorded across two sectors (from sector No. 0 

to sector No. 1), it is necessary to know where the next timestamp information is recorded when the reproduction is 

started from the leading portion of second or any subsequent ECC block. 
35 [0287] For this, special header information (cf. the sector data header as shown by (a) in FIG. 26) is arranged at the 

leading portion of each sector. By recording the first access point 651 in the special header information, it is possible to 

easily start the reproduction from the leading portion of the second or any subsequent ECC block in the stream block. 

[0288] SOB (stream object) is stream data which belongs to an original PGC (program chain). Ttie data structure 

of SOB complies with Program Stream prescribed in "Information Technology-Generic coding of moving pictures and 
40 associated audio: Systems (ISO/IEC 1 3818-1)". A SOB is formed of only one type of data, that is stream data. 

[0289] SOB data structure is defined as a sequence of Stream Packs, which have a fixed size of 2048 bytes. This 

is the same size as the Logical Block size of the DVD disc family, and every Stream Pack shall be recorded in a Logical 

Block. 

[0290] FIG. 27 describes constraints on MPEG specifications for SOB. 
45 [0291] More specifically, (1) a system header shall not be included in SOB; (2) a SCR (System Clock Reference) 
value in the first pack of SOB may have any value; (3) an MPEG_program_end_code shall not be included in SOB; and 
(4) a streamed shall be equal to BFh (private_stream_2) in all PES packets. 

[0292] Navigation data is provided to control the recording, playing back (or reproducing), and editing of any bit- 
streams. In DVD Stream Recording, navigation data is called "Streamer Information (STRI)". 
so [0293] FIG. 28 shows the structure of navigation data (corresponding to control information 25 in FIG. 9) contained 
in DVD streamer information (STRI). As shown in FIG. 28, streamer information STRI is constituted by the following 
information. 

[0294] That is, STRI is constituted by (1) Streamer video Manager (STR_VMGI); (2) Stream File Information Table 
(SFIT); (3) Original PGC Information (ORG_PGCI); (4) User Defined PGC information Table (UD.PGCIT); (5) Text Data 
55 Manager (TXTDTJvlG); and (6) Application Private Data Manager (APDT_MG). 

[0295] STR_VMGI, SFIT, ORG_PGCI, UD_PGCIT, and TXTDT_MG of FIG. 28 are recorded in a file named 
"SR_MANGR.IFO" in this order. 

[0296] On the other hand, APDTJvlG of FIG. 28 is recorded in another file named "S R_ADATA. DAT . 
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[0297] Stuffing coded as "00h" may or may not be inserted between tables of above (1)-(6) unless the size of STRI 
exceeds 51 2 kB, but no stuffing shall be inserted within a table of above (1 )-(6) 

[0298] Incidentally, most of information described in SR_MANGER.IFO is supposed to be kept in the system mem- 
ory o1 streamer instruments (e.g., FIG. 14). 
5 [0299] Streamer Video Manager Information STR_VMGI of FIG. 28 is formed of Video Manager Information Man- 
agement Table (VMGI_MAT) and Play List Search Pointer Table (PL_SRPT). 
[0300] FIG. 29 shows the structure of Stream File Information SFIT shown in FIG. 28. 

[0301] Stream File Information SFIT contains all navigation data which are directly relevant to the Streamer opera- 
tion. As shown, SFIT is formed of one instance of Stream File Information Table Information (SFITI), zero or more 
70 instances of Stream Object Stream Information (SOB_STI), and zero or one instance of Stream File Information (SFI). 
[0302] Stream File Information Table Information SFITI includes SFI_Ns indicating the number of stream files; 
SOB_STI_Ns indicating the number of SOB stream information items; SFIT_EA indicating the end address of SFIT; 
and SFI_SA indicating the start address of SFI. 

[0303] FIG. 30 shows the structure of Stream File Information SFI shown in FIG. 29. 
is [0304] As shown. Stream File Information SFI is formed of (1) Stream File General Information (SFJ3I); (2) one or 
more (n pieces) SOB Information Search Pointers (SOBI_SRP#n); and (3) one or more (n pieces) SOB Information 
(SOBI#n). 

[0305] FIGL 31 shows the contents of Stream File General Information SF_GI shown in FIG. 30. 
[0306] Stream File General Information SF_GI includes SOBI_Ns indicating the number of SOBIs; SOBU_SIZ indi- 
20 eating the size of SOBU by the number of sectors per SOBU; and MTU_SHFT indicating a mapping time unit shift. 
[0307] SOBU_SIZ describes the size in sectors of the SOBU, and is defined as the fixed value 32. This means that 
in each mapping list the first entry relates to the application packets contained in the first 32 sectors of the SOB, the 
second entry relates to the application packets contained in the next 32 sectors, and so on. 

[0308] The mapping time unit shift MTU_SHFT describes the weight of the LSB (least significant bit) of the mapping 
25 list entries, relative to the bits of the PAT describing format. This MTU_SHFT shall be described as 18. 
[0309] FIG. 32 shows the structure of Stream Object Information (SOBI#) shown in FIG. 30. 
[0310] As shown, each Stream Object Information SOBI is formed of (1) Stream Object Information General Infor- 
mation (SOBIJ3I); (2) Mapping List (MAPL); and (3) (optional) Access Unit Data (AUD). 

[031 1] FIG. 33 shows the contents of Stream Object Information General Information SOBI_GI shown in FIG. 32. 

30 [0312] As shown in FIG. 33, Stream Object Information General Information SOBI_GI includes (1) SOB_TY indi- 
cating the type of SOB; (2) SOB_REC_TM indicating the recording time of SOB; (3) SOB_STIJ\l indicating the stream 
information number of SOB; (4) AUD_FLAGS indicating the flags of Access Unit Data (AUD); (5) SOB_S_APAT indicat- 
ing the start APAT (Application Packet Arrival Time) of SOB; (6) SOB_E_APAT indicating the end APAT of SOB; (7) 
SOB_S_SOBU indicating the first SOBU of the SOB; and (8) MAPL_ENT_Ns indicating the number of Mapping List 

35 entries. 

[031 3] SOB_TY describes the Stream Object Type, containing bits for Temporal Erase state and for Copy Genera- 
tion Management System. 

[0314] SOB_REC_TM describes the recording time of the associated Stream Object in DVD Stream Recording's 
Date and Time Describing Format. 
40 [031 5] SOB_STI_N describes the index of the SOB_STI which is valid for this SOB. 

[031 6] AUD_FLAGS describes whether and what kind of Access Unit Data (AUD) exists for this SOB. If AUD exists, 
then AUD_FLAGS also describes several properties of the AUD. 

[0317] The AUD itself is constituted by some general information including the table AUSM and the optional tables 
AUEM and PTSL (Presentation Time Stamp List; cf. FIG. 34). 
45 [0318] SOB_S_APAT describes the start Application Packet Arrival Time of the Stream Object, i.e., the packet 
arrival time of the first packet belonging to the SOB. SOB_S_APAT is described in DVD Stream Recording's PAT 
Describing Format. 

[031 9] PATS (Packet Arrival Times) are divided into two parts, namely a base part and an extension part. The base 
part holds the so-called 90 kHz unit value, and the extension part holds the less significant value measured in 27 MHz. 
so [0320] SOB_E_APAT describes the end Application Packet Arrival Time of the Stream Object, i.e., the packet 
arrival time of the last packet belonging to the SOB, in DVD Stream Recording's PAT Describing Format. 
[0321] SOB_S_SOBU describes the number of the start Stream Object Unit, i.e., the Stream Object Unit containing 
the first Application Packet of the Stream Object. 

[0322] MAPL_ENTJsls describes the number of Mapping List entries to follow after SOBI_GI. 
55 [0323] FIG. 34 shows the structure of Access Unit Data AUD shown in FIG. 32. 

[0324] Access Unit Data AUD (optional), if any is formed of (1) Access Unit General Information (AU_GI); (2) 
Access Unit End Map (AUEM); and (3) Presentation Time Stamp List (PTSL). Which of these parts exist may be indi- 
cated by AUD_FLAGS of SOBI_GI. 
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[0325] AU_GI only exists, when AUD_FLAGS of SOBI_GI indicates that Access Unit Data exists. 
[0326] FIG. 35 shows the contents of Access Unit General Information AU_GI shown in FIG. 34. 
[0327] Access Unit General Information AUGI includes AU_Ns indicating the number of Access Units, and AUSM 
indicating Access Unit Start Map (MAPL_ENT_Ns elements). 

[0328] AU_Ns describes the number of Access Units for SOB. At the same time, AUJMs describes the number of 
locations of Access Units, where AUSM indicates the existence of an Access Unit. 

[0329] The Access Unit Start Map (AUSM) indicates which of SOBUs of the SOB contain Access Units. For each 
SOBU of the SOB, exactly one AUSM element exists. So, the AUSM is formed of MAPL_ENT_Ns elements. 
[0330] Each AUSM element indicates an accessible Access Unit beginning somewhere within the corresponding 
SOBU, or within the subsequent SOBU. Exactly AU_Ns Access Units are indicated by the AUSM, equivalent to exactly 
AU Ns bits of AUSM being equal to 1 b (binary bit "1 n ). 

[0331] AUSM shall be byte aligned. If the concatenated AUSM elements are formed of a number of bits which is not 
an integer multiple of 8. then the remaining LSBs (least significant bits) of the last byte of the AUSM shall be padded 

[0332] b ^'"rG illustrates an example of correspondence between Access Unit Start Map AUSM (Cf. FIGS. 8 and 
10) and stream object units SOBUs (cf. FIGS. 2, 4, and 1 1). 
[0333] As will be seen from the illustration, each portion of bit "1 " in AUSM indicates that the corresponding SOBU 
contains Access Unit (AU#). ^ 
[0334] Assume that AUSM_pos(i) is the bit position of the i-th set bit in AUSM (i * i * AU_Ns). Under this assump- 
20 tion, the location of the AU can be defined as follows: 

(1) If SOBU#i, indicated by AUSM_pos(i), contains more than one starting AU described by AU_START and 
AU_END marks (if any) inside the stream, then AUSMjx)s(i) is assigned to the first AU starting in SOBU#i which 
is located inside the SOBUs described by AUSM_pos(i) and (if AUEM exists) AUEM_pos(i). 
25 (2) An AU ends with the first occurring AU_END mark after the start of this AU, and an AU ends with the last SOBU 
indicated by the assigned AUEM element (H AUEM exists). . 

[0335] Note that with this kind of Access Unit Data, no more than one addressable Access Unit can be described 
per each SOBU of the SOB. 

30 [0336] FIG 37 illustrates an example of correspondence between Access Unit Start Map AUSM (cf. FIGS. 8 and 
10) with Access Unit End Map AUEM (cf. FIGS. 8 and 10) and stream object units SOBUs (Cf. FIGS. 2, 4, and 11). 
[0337] AUEM, if exists, is a bit array of the same length as AUSM. The bits in AUEM indicate which of the SOBUs 
contain the end of the bitstream segment associated with the Access Units of the SOB. 

[0338] The number of bits set in AUEM shall be equal to the number of bits set in AUSM. i.e., each set bit in AUSM 

35 has its corresponding set bit in AUEM. 

[0339] Assume that AUSM_pos(i) is the bit position of the i-th set bit in AUSM (i * i s AUNs), and that AUEMj)os(i) 
is the bit position of the i-th set bit in AUEM (i <; i <L AU_Ns). Under this assumption, the following conditions are obtained: 

(1) 1 <> AUSM_jD0S(i) <; AUEMjXDS(i) <> MAPL_ENT_Ns; 
40 (2) AUSM_pos(i+1 ) > AUEM_pos(i); 

(3) if i == AU_Ns. or if AUSM _pos(i+1) > 1+AUEMj>os(i), then AU#i ends in SOBU#[AUEM_pos(i)], where 1 <> i £ 

AU Ns* 

(4) " if AUSM _pos(i+1) == 1+AUEM_pos(i), then the AU#i ends in SOBU#[AUEM_pos(i)], or ends in 
SOBU#[1+AUEM _pos(i)) == SOBU#[AUSM_pos(i+1)]. Thus, AU#i may end in the SOBU in which AU#i+1 starts (1 

45 < i £ AU_Ns). 

[0340] FIG. 38 shows the structure of one stream pack (corresponding to TS pack shown in FIGS. 2-4). 

[0341] As shown, one stream pack (2048 bytes) is formed of a pack header (14 bytes) and a stream PES packet 

(2034 bytes). , . , 

so [0342] The pack header of the stream pack has 14-byte size. The first 4 bytes (000001 BAh) of the pack header 
record a pack start code. Next 6 bytes of the pack header are defined by a provider and they record the base of system 
clock reference (SCR_base; total 32 bits), marker bits, and the extension of system clock reference (SCFLextension; 9 
bits) The subsequent 3 bytes (0189C3h) of the pack header record a program-multiplex rate (program_mux_rate; 22 
bits) and marker bits. The last 1 byte (F8h) of the pack header records a pack stuffing length (pack_stuff ing length; 3 
55 bits) and has reserved area (5 bits). n 

[0343] Note that the 32nd bit of the SCR_base[32] shall be set to zero and the "program„mux_rate shall be set to 

[03^] MbP ^n stream recording, the application performs its own stuffing, so that the pack length adjustment methods 
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of DVD-ROM Video or DVD-VR need not be used. In stream recording, it is safe to assume that the stream packets will 
always have the necessary length. 

[0345] The stream PES packet of the stream pack has the following data structure. 
[0346] FIG. 39 shows the structure of stream data area in the stream PES packet shown in FIG. 38. 
5 [0347] As shown, one stream PES packet (2034 bytes) is formed of a PES header (6 bytes), a substream ID (1 
byte) . and a stream data area (2027 bytes). 

[0348] The first 3 bytes (000001 h) of the PES packet header of stream PES packet record a prefix of packet start 
code (packet_start_code_prefix; 24 bits). The next 1 byte records a stream ID (streamjd = 10111111b; 8 bits). The 
subsequent 2 bytes (07ECh) record a length of PES packet (PES_packetJength). The last 1 byte records a substream. 

io ID (sub_stream_id = 0000001 0b; 8 bits). 

[0349] The stream data area (2027 bytes) inside a stream packet shown in FIG. 39 is formed of an application 
header (9 bytes), an optional application header extension, an optional stuffing byte, and an application packet area. 
[0350] The application packet area of FIG. 39 is filled with a sequence of one or more application packets each pre- 
fixed by an application timestamp (corresponding to ATS in FIG. 3 or FIG. 24). 

is [0351] The application packet area may have a configuration similar to (b) in FIG. 3 (the TS" packet of FIG. 3 is 
replaced with the application packet of FIG. 39). More specifically, a partial application packet may be recorded at the 
start of the application packet area. After the partial application packet, a plurality of pairs of application timestamps 
(ATSs) and application packets are sequentially recorded. At the end of the application packet area, a partial application 
packet may be recorded. 

20 [0352] In other words, at the start of the application packet area, there may exist, in general case, a partial applica- 
tion packet At the end of the application packet area, there may exist, in general case, another partial application 
packet or a stuffing area of "reserved" bytes. 

[0353] The application timestamp (ATS) in front of each application packet has a 32-bit value. An ATS is divided into 
two parts, namely a base part and an extension part The base part holds the so-called 90 kHz unit value, and the 

25 extension part holds the less significant value measured in 27 MHz. 

[0354] In FIG. 39, the application header extension is used to store information that can differ from application 
packet to application packet. This kind of information may not be required for all kinds of applications. 
[0355] Therefore, a data field in the application header is defined to describe the presence of the optional applica- 
tion header extension in the stream data area. 

30 [0356] At stream recording, the first byte of the application timestamp ATS of the first application packet shall be 
aligned to the start of the application packet area in the first stream packet at the beginning of a stream object SOB. 
[0357] Any following stream packets in a SOB may split (or divide) application packets across stream packet bound- 
aries. The partial application packets shown in FIG. 39 are examples of the resultant split (or divided) application pack- 
ets. 

35 [0358] The byte offset of the first application timestamp that starts in a stream packet, as well as the number of 
application packets starting in the stream packet, shall be described in its application header (cf. FIG. 40). 
[0359] This mechanism automatically allows for stuffing in front of the first application timestamp and after the last 
application packet in a stream packet. 

[0360] The above automatic mechanism corresponds to "the application performs its own stuffing" described in the 
40 explanation of FIG. 38. By means of such automatic stuffing, the stream packet can always have a necessary length. 
[0361] The optional application header extension is formed of a list of entries, where there is exactly one entry of 1 
byte length for each application packet which starts in the stream packet. These bytes of the entries are used to store 
information that may differ from application packet to application packet. 

[0362] In the optional application header extension (1 byte), AU.START (1 bit), AU_END (1 bit), and COPYRIGHT 
45 (2 bits) are described. 

[0363] When AU_START is set to "1", this indicates that the associated application packet contains a random 
access entry point (start of a random access unit) in the stream. 

[0364] When AU_END is set to "1" , this indicates that the associated application packet is the last packet of a ran- 
dom access unit. 

so [0365] COPYRIGHT describes the copyright status of the associated application packet. 

[0366] FIG. 40 shows the contents of the application header at the start of the stream data area shown in FIG. 39. 
[0367] The application header contains 1-byte VERSION (01h); 1-byte AP_Ns; 2-byte FIRST_AP_OFFSET; 2-bit 
EXTENSION_HEADER_INFO (00b, 10b; or 11b); 1-bit reserved for CCI_ESC; 5-bit reserved area; 2-byte 
SERVICEJD; 1 -byte MAX_BR_LOG2; and 1-byte SMO_BS_LOG2. 

55 [0368] The VERSION describes the version number of the application header format. 

[0369] The AP_Ns describes the number of application packets which are starting in the stream packet. An appli- 
cation packet is considered to be starting in a stream packet, if the f irst byte of its application timestamp is stored in that 
stream packet. 
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[0370] The FIRST_AP_OFFSET describes the position of the timestamp of the first application packet, which starts 
in the stream packet, relative to the first byte of the stream pack, in bytes. If no application packet starts in the stream 
packet, FIRST_AP_OFFSET shall be set to n 0\ 

[0371] The EXTENSION_HEADERJNFO describes whether an application header extension and/or a stuffing 
byte exist in the stream pack. 

[0372] When EXTENSION_HEADER_INFO = 00b. no application header extension follows this application header 
and no stuffing byte exists. 

[0373] When EXTENSION_HEADERJNFO = 10b, an application header extension follows this application header 
but no stuff ing byte exists. 

[0374] When EXTENSIONJHEADERJNFO = 1 1 b, an application header extension follows this application header 
and a stuffing byte exists after the application header extension as well. 
[0375] Here, EXTENSION_HEADER_lNFO = 01b is prohibited. 

[0376] The optional stuffing byte in front of the application packet area can be activated 
(EXTENSIONJHEADERJNFO = 1 1b) to avoid a "packing paradox", where a contradiction exists between the number 
is of bytes in the application header extension and the number of application packets which can be stored in the applica- 
tion packet area. 

[0377] The SERVICEJD describes an ID for the service that generated the stream. If the service is unknown, 
0x0000 shall be described. 

[0378] The MAX_BR_LOG2 describes the binary logarithm of the output bitrate parameter of the leaky bucket flow 
20 control model. 

[0379] The SMO_BS_LOG2 describes the binary logarithm of the buffer size parameter of the leaky bucket flow 

control model . 

[0380] To restate, according to the present invention. AUSM, AUEM and/or support information can be recorded 

and, hence, user friendly data management can be achieved. 
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Claims 

1 . An information medium characterized by comprising: 

30 an data object (VOB/SOB) formed of one or more data object units (VOBU/SOBU) each of which serves as a 

prescribed data unit; 

control information (VOBUl/SOBI) of said data object (VOB/SOB); 

access unit data (AUD) used for accessing an access unit (l-picture, etc.) which is a part of contents of said 
data object (VOB/SOB), said access unit data (AUD) being contained in said control information 
35 (VOBUl/SOBI); and ^ ^ x 

a bitstream being formed of a series of packets, said bitstream including contents of said data object 
(VOB/SOB) and contents of said control information (VOBUl/SOBI). 

2. The medium of claim 1 , characterized in that said access unit data (AUD) includes at least one of: 

40 

first information (REFPICSA#/AUSM) indicating which of said data object units (VOBU/SOBU) contains said 
access unit (l-picture, etc.); and 

second information (REFP ICEA#/AUEM) indicating which of said data object units (VOBU/SOBU) contains an 
end of a segment of said bitstream, said segment being associated with the access unit (l-picture, etc.) of said 
45 data object (VOB/SOB). 

3. An information medium characterized by comprising an data object (VOB/SOB) formed of one or more data object 
units (VOBU/SOBU) each of which serves as a prescribed data unit; control information (VOBUl/SOBI) of said data 
object (VOB/SOB); access unit data (AUD) used for accessing an access unit (l-picture, etc.) which is a part of con- 
so tents of said data object (VOB/SOB), said access unit data (AUD) being contained in said control information 

(VOBUl/SOBI); and a bitstream being formed of a series of packets, said bitstream including contents of said data 
object (VOB/SOB) and contents of said control information (VOBUl/SOBI), 
characterized in that said packets include: 

55 one or more stream packets containing one or more application packets; and 

partial application packets obtained by splitting said application packets across boundaries of said stream 
packets. 
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4. The medium of claim 3. characterized in that said packet includes an application header extension being used to 
store information that can differ from one application packet to another application packet. 

5. The medium of claim 3, characterized in that each of said application packets has an application timestamp at the 
leading portion thereof. 

6. A method of recording bitstream information that comprises an data object (VOB/SOB) formed of one or more data 
object units (VOBU/SOBU) each of which serves as a prescribed data unit; control information (VOBUI/SOBI) of 
said data object (VOB/SOB); access unit data (AUD) used for accessing an access unit (l-picture, etc.) which is a 
part of contents of said data object (VOB/SOB), said access unit data (AUD) being contained in said control infor- 
mation (VOBUI/SOBI); and a bitstream being formed of a series of packets, said bitstream including contents of 
said data object (VOB/SOB) and contents of said control information (VOBUI/SOBI), 

characterized in that said bitstream information is recorded on an information recording medium (S21 of FIG. 16). 

7. A method of recording bitstream information on an information recording medium (S21 of FIG. 16), said bitstream 
information characterized by comprising an data object (VOB/SOB) formed of one or more data object units 
(VOBU/SOBU) each of which serves as a prescribed data unit; control information (VOBUI/SOBI) o1 said data 
object (VOB/SOB); access unit data (AUD) used for accessing an access unit (l-picture, etc.) which is a part of con- 
tents of said data object (VOB/SOB), said access unit data (AUD) being contained in said control information 
(VOBUI/SOBI); and a bitstream being formed of a series of packets, said bitstream including contents of said data 
object (VOB/SOB) and contents of said control information (VOBUI/SOBI), 

characterized in that said packets include one or more sequential or continuous stream packets containing one or 
more application packets; and partial application packets obtained by splitting said application packets across 
boundaries of said sequential or continuous stream packets, 

that each of said application packets has an application timestamp at the leading portion thereof, 
and that, when said bitstream information is recorded on said information recording medium, a first byte of said 
application timestamp of a first one of said application packets is aligned to a start of an application packet area 
in a first one of said stream packets ("etc." in S20 of FIG. 15). said first one of said stream packets being 
located at beginning of said data object (VOB/SOB). 

8. The method of claim 6 or 7, characterized in that said packets include one or more stream packets containing one 
or more application packets; 

and that said application packets are split across boundaries of said stream packets to provide partial applica- 
tion packets (S22-S23 of FIG. 16). 

9. A method of reproducing (FIG. 19) bitstream information that comprises an data object (VOB/SOB) formed of one 
or more data object units (VOBU/SOBU) each of which serves as a prescribed data unit; control information 
(VOBUI/SOBI) o1 said data object (VOB/SOB); access unit data (AUD) used for accessing an access unit (l-picture, 
etc.) which is a part of contents of said data object (VOB/SOB), said access unit data (AUD) being contained in said 
control information (VOBUI/SOBI); and a bitstream being formed of a series of packets, said bitstream including 
contents of said data object (VOB/SOB) and contents of said control information (VOBUI/SOBI), 
characterized in that contents of said bitstream is reproduced from said bitstream information based on said access 
unit data (AUD). 

1 0. A method of reproducing (FIG. 19) bitstream information that comprises an data object (VOB/SOB) formed of one 
or more data object units (VOBU/SOBU) each of which serves as a prescribed data unit; control information 
(VOBUI/SOBI) of said data object (VOB/SOB); access unit data (AUD) used for accessing an access unit (l-picture, 
etc.) which is a part of contents of said data object (VOB/SOB), said access unit data (AUD) being contained in said 
control information (VOBUI/SOBI); and a bitstream being formed of a series of packets, said bitstream including 
contents of said data object (VOB/SOB) and contents of said control information (VOBUI/SOBI), 
characterized in that contents of said bitstream is reproduced from said bitstream information, based on said 
access unit data (AUD). 

that said packets include one or more sequential or continuous stream packets containing one or more appli- 
cation packets; and partial application packets obtained by splitting said application packets across boundaries 
of said sequential or continuous stream packets, 
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that each of said application packets has an application timestamp at the leading portion thereof, 
and that, when a first byte of said application timestamp of a first one of said application packets is aligned to 
a start of an application packet area in a first one of said stream packets located at beginning of said data 
object (VOB/SOB), the split one of said partial application packets is reproduced based on contents (packet 
access pointer =0 & 0x2e of FIG. 3; or application header of FIG. 39) of access information provided in said 
stream packets (S63 of FIG. 19). 

1 1 . A stream information recording apparatus for recording received stream information with support information, char- 
acterized by comprising: 

means (80B in FIG. 14; S1 1 in FIG. 15) for preparing management information relating to the stream informa- 

means (80C in FIG. 14; S1 8 in FIG. 1 5) for detecting the support information relating to the stream information; 
means (80D in FIG. 14; S19 in FIG. 15) for adding the detected support information to the prepared manage- 
J5 ment information; and 

means (51-53 79 in FIG. 14; S21-S28 in FIG. 16) for recording on a recording medium (50 in FIG. 14) the 
received stream information and the prepared management information to which the detected support informa- 
tion is added. 

12. The apparatus of claim 1 1 . characterized in that said stream information contains a prescribed access unit (e.g., 1- 
picture), and said support information includes at least one of: 

information indicating a start position of said access unit (REFPIC_SA#/AUSM in FIG. 10); and 
information indicating an end position of said access unit (REFPIC_EA#/AUEM in FIG. 10). 



20 



25 



30 



35 



40 



45 



50 



55 



23 



BNSDOCID: <EP 1021048A2J_> 



EP 1 021 048 A2 




CO 



24 



BNSDOCID: <EP. 



.1021048A2J_> 



EP 1 021 048 A2 



CO 



UJ 

o — 

O CO 
LU p 
O > 



Y- 




O 




LU 


CO 


~3 




CD 


o 


O 


"~l 


O 


CD 


UJ 


O 


o 


> 






> 




I— 




o 




UJ 


CNJ 


~> 




CO 


o 


o 




O 




UJ 




Q 


g 






> 








o 




UJ 




~> 




CQ 




O 




o 


*' 


UJ 


O 


o 


> 






> 





-J o 



CO 



CD 

8 



CO 

o 



I — 



UJ — 



UJ 

o 



CO 

o 
o 



CO 

-J z 

— I Q 
UJ — , 



-J o 

UJ — , 



its 

~J o 
o «2 



11 

> ^ 



CO 



UJ CD 

*~i o 

CD CO 
O 

O zd 

UJ CD 

O O 

— > 
> 



CD 3) 
O CD 

o? 

LU 
O 



CD 
O 
CO 



o 

LU 
O 



co^ 



65 



CL 



CO o 



CO o 

< 

CL 



CO o 

< 
a. 



CL 



CO o 

•-2 



Cl 



Csl 

CD 



o 



25 



BNSDOCID: <EP_ 1021048A2J_> 



EP 1 021 048 A2 



CO 



2 



CL 



co cj 
<£ 
a. 



00 o 

- <c 

CL 



CO o 

•2 



00 



o 

Ql 



CO 

uj 

CD 



CO 



LU 



CO 
UJ 

CO 



CO o 

- < 

CL 



CO 



CL. 



O0 

in 



CD 



o 

2 



UJ 

o 

CO < 

cl 



LU 

UJ 

<c _j 

CL CL 
Q_ 
CO < 



Si 



CC «+- 



X 

o 
II 

o 



CO — 



CC JD 

UJ X 

o o 

rc — 



LU 
O CC 

<c : 

CL CO 



DC 
UJ 

^ o 

< 55 

a. x 



CD 
CO 



CNJ 



CL 

<: 
y- 
co 

UJ 



CO 

V- CO 
< CO 



CO 



CO 



CL 

00 00 
UJ t- 

>- LL 
CD O 

CO LU 

ac 
O 3 

CNJ h- 

ID 
QC 
H- 
00 

CO 
CO 



CL 

CO 
. LU 

CO 

< 

CO 



CO 
LU 
I— 
>- 
CD 

CO 
00 



CO 
UJ 

CSl 



LU 
CO 



00 
LU 

CD [ 

co >r 

CO CD 



00 

CO J— 
CO 



LU O 
00 



CL 
CL 
< 



LU 



LU 
LU 

^ . 

< -J 
CL CL 
CL 
CO <t 



CO 
CO 
LU 

O O 

<: n 

DC 

I— LU 

LU I— 

O — 

<t o 

a. a. 



u) o 

ac M- 

l— x 

CO o 

CO II 

ZD Q 

CO — 



DC JQ 

LU X 

Q O 

S5 O 

IC — 



LU < 
^ LU 
O CC 

< : 

CL CO 



^ o 
o 



CD 
CO 



00 



CD 
CD 



00 
LU 

& 

CO 

o 

CNJ 



GO 



COM 
CO LU 

cov 



CO 
CO 



CO 
LU 
I — 
>- 
CD 

CD 



oo 

LU 
I— 
>- 
CO 

CNJ 



i LU 

CO ^ CO 
CL 



.to 

CO 



00 
LU 

CO 



CO 

, ir> _ _ lu 
°o ^ 

CO 



ULi 

CL . 

CO 3 
CL 



UJ 

o 

CO < 
I — CL 



5 

LU 

cl 

0- Z i 



CO 



CO 

CO © 
LU CNJ 



.CD 
CO 



o 

2 

>- UL 
GO O 

CO LU 
^ DC 
O ZD 

™& 

DC 



CO 
CO 



o 



UJ 

o 

CL 



2 o 

I— X 
CO o 

§^ 

CO — 



LU X 
Q O 

55^ 



LU < 
^ LU 
CJ> DC 
<C I— 
CL CO 



DC 
LU 

0- X 



CO 
UL 



.o 



co 



< 

CL 
O 

CNJ 



.to 

CO 



LO 

' CO 



(0 



26 

BNSD0CID: <EP 1021048A2_L> 



EP1021 048 A2 

















CD 






o 






CO 












z> 






CD 






o 
























CD 






























CO 




























































CO 






















1 


> s> 






LU 






f— \ 




J CO ^ 


Cft 
W J 




> CO 








ZD 












8 
























CO 






o 






c/> 


















=> 






'CO 






o 










( 














CO 












§ 


















CO 























ItD 



CO 



go o 



oo o 



CO o 

•-2 



CO 



00 



0- 



1 

CO 

00 
00 



LU 



CO 



CD 



CO 



*oo 

CO 



LU 
CO 



CO 
CO 
LU 

o 
o 
< 

2 



cc 

LU 



IS 

cc 
I— 
CO 
CD 
ZD 
CO 



cc 

LU 

o 
<: 

LU 
Q_ 



to 



cc 

LU 
CL DC 



.CD 

CO 



CO CO 

>- LL 
CO o 

CO LU 

cc 

O ID 
C\J I— 

o 
r> 
cc 

I — 
CO 



o 

LL. 



.in 

CO 



27 



BNSDOCtD: <EP. 



1021048A2J_> 



EP 1 021 048 A2 



co 
co lu 

CD 



00 
CO UJ 

CD 



CO 
LU 
I— 
>- 
CD 

CO 
CO 



LLf 



>- 
CD 



LLf 
I— 
>- 
CD 



00 
LU 

CD 



00 Jl 

'I 

CD 



OJ 
LU O 



3 

Q_ 

CL 



_ < 
o — 



QC < 
O Cl 
Q- ^ 



O 
00 < 
Q_ 



CL 
LU 

<C — f 
CL CL 
CL 
00 < 



II 

o 



00 

o 



— LU 

o < 



LU O 
£ X 

00 o 
CD 

ZD _ 
00 — 



T3 
QC X> 
LU X 
O O 

or — 



LU <C 

S*£ LU 

o cc 

< : 

CL CO 



cr 
o <; 

< LL 

o_ n: 



, cx> 

CO 



CO 

to tfJ 

CD 



coA 

00 LU 

52 

C0y 



. CO 
CO 



00 
UJ 

CO 

o 

CM 



CO 



CO 



CO 

' CO 



LO 

' CO 



CO 



CD 
LO 



LU 

>- 
CD 



. LU 



CO 
LU 



00^ 

-I 

CO 



LU 

I 

00 



LU 

2 



CC 

2 



00 



^ CL 

o 

2-, 



O UL 



— LU 

I — ^ 

o <t 

O CL 



2, 

CC « 
I— X 

00 o 
CD II 
ZD O 
CO — 



JD 
X 



a 



UJ 

Cl 00 



cc 

LU 



3 



. cn 

CO 



. co 

CO 

CL 
00 00 

5- LL 
CD O 

CO LU 

<=r cc 

O ZD 

cc 



2 

CO < 



CM 



, CD 
CO 



LO 
CO 



28 



BNSDOCIO. <EP 1021048A2_I_> 



EP1 021 048 A2 



O 
CD 

CL 



O 

o 



8 

Q_ 

I 



7 
3 



3* 

CL 
GC 
CO 

J 
cd 
a. 



CL 

o 
cd 

CO 











o 








UL 








z: 








-J 








o 








cc 












I- 




£ 




CL 




o 




cr 




o 


< 


CO 


o 




I 


CD 






—j 


Q_ 






a. 


o' 


o 


O 












3 




> 














a: 
















g 


< 




O 




I 




PG 


CO 


CO 


CO 


i 

CO 











c 

QC 

3 

cd 

3 



c 

CL 
CC 



O 

cd 

CL 

ID 



CO 



C 

o 

CD 
IX 



c 



o 

CD 



CO 



CO 



o 

CO 



CL 
< 

Q 

<, 



CD 
O 
> 

00' 



o 

00 



CD 

3 









LU 






"OS) 




(SC. 








PBI 




_PBI 






o 



T 



n 



O 
CD 

a- 















































^= 
















J_ 












s 












o 








CO 


CO 


0- 


g 






MA 






CD 






3 








3 


C0 








CL 


CL 


CD 


CD 


1 




a. 


a. 





CO 



CD 

cd 



29 



BNSDOCID: <EP 102104BA2_I_> 



EP 1 021 048 A2 



PGC.GI (SC_GI) 





CONTENTS 




Ml IUQCD AP PDftftDAMC Ml I1IDCD AC PCI 1 C 
NUMDCn Ur rnUonAMo, NUMDCn Ur vCLLO 


nrr TOO Til 


iCvUnU I Tvo 1 1 Mt r cn rou 


r>1 innADT 1 MCA 

SUPPOHI INK) 


CI IDDADT 1 MCADUAT I AM fnCTAIIC ADC 1 1 QTCh PCI AUA 

oUrrUH 1 1 NrUnMA 1 1 UN VUt 1 A 1 Lo Ant L 1 o 1 fcU DfcLAW 


^GCJ^GMAP^SA 


OTADT AnHDCOO AC DDAPDAM 16 AD 

olAHl AuUnboo Ur rnUbnAM MAP 


C_PBIT_SA 


OTADT AAADCOO AC A DDIT 

oIAnl AUDHtbo Ur C_PBI 1 




olAnl AUuncoo vr L_ruoi t 


ARCHIVE FLAG 
(C TY1 A TF} 


CDAOC 1 kill 1 D IT 1 AM CI Af* 

tRAbc INHIdIIIUN rLAG 

0" FREE 1" SAVE PERMANENTLY 


Ov Li 1 Jig 


NUMBER OF ENTRY POINT INFORMATION 

1 «W(VIL/L»J 1 wl L..IV 1 1 1 1 1 Villi 111* VI Ufin 1 1 VII 


S0B_N 


STREAM OBJECT NUMBER 


SC_S_APAT 


STREAM CELL START APAT 


SC_E_APAT 


STREAM CELL END APAT 


if (TE^'IObOl 




ERA_S_APAT 


ERASE START APAT 


ERA_£_APAT 


ERASE END APAT 


b7 b5 


b4 b3 b2 bl bO 



(a) 



(b) 



IDENTIFICATION 
Y CODE OF STB 
MTHAT RECORDED 
DATA 



SCD 
SUPPORT 



PCR 
SUPPORT 



RANDOM ACCESS 
INDICATOR SUPPORT FLAG 

Ob- "NOT SUPPORTED, 

lb- -SUPPORTED 
UNIT START INDICATOR 
SUPPORT FLAG 

Ob- -NOT SUPPORTED, 

1b- -SUPPORTED 
PAT, PMT SUPPORT FLAG 

Ob- -NOT SUPPORTED, 

lb- -SUPPORTED 
PCR SUPPORT FLAG 

Ob- -NOT SUPPORTED, 

lb- SUPPORTED 
SCD SUPPORT FLAG 

Ob- -NOT SUPPORTED, 

1b- SUPPORTED 
PCR=PRESENTAT I ON CLOCK 

REFERENCE 
SCD=SPLICE COUNTDOWN 



PAT, 
PMT 

SUPPORT 



UNIT START 

INDICATOR 

SUPPORT 



RANDOM 
ACCESS 
INDICATOR 
SUPPORT 



STB IDENTIFICATION CODE 

001 : STB OF BS DIGITAL BROADCAST 

010:Ver2 STB OF DirecTV 

01T.Ver1 STB OF SKY PERFECT TV 

C TYI-'OlOb' SHALL BE DESCRIBED 
FOR ALL STREAM CELLS 

TE-W.THIS CELL IS IN THE 
"NORMAL" STATE 

'Olb'lTHIS CELL IS IN TEMPORARILY mrm% 
ERASED" STATE; AND THIS CELL STARTS 
AFTER THE FIRST APPLICATION PACKET 
OF A SOBU AND ENDS BEFORE THE LAST 
APPLICATION PACKET OF THE SAME SOBU 

'1 Ob': THIS CELL IS IN "TEMPORARILY 
ERASED" STATE; AND THIS CELL 
CONTAINS AT LEAST ONE SOBU 
BORDER (FIRST OR LAST 
APPLICATION PACKET OF A 
SOBU). ERA_S_APAT AND 
mjJPKY EXIT FOR THIS CELL _ 

FIG.7 



30 



BNSDOCID: <EP 1021048A2_I_> 



EP 1 021 048 A2 



00 CD 

U- 
O 



CO 



LU 



8 



O 
00 



CO 
Q- 

I 



LU 



u_ 

I O I 



LU 

o I 



Q 
LU 



I 

O I 

cc 

— . ° 

LU O 



LU 
O I 

LL 
O 



DC 



2 



CC 
<J> 
CL 



CNJ 1 OC 

o I o 

LU LU 
_ ,CJ> 

uj : 



gl 
-.5 

I o o 
co I co 

CO CO 
LU I LU 

ss 

33 



LU 1 O 
X 

^- , ° 
o 



CD 1 <C 

LL O 
O 



|LU 

111" 

CO 1 CL I O 

a U k 

o I o 



Ct- 
CO 

cc 



be] cc 



oo 

LU 
CC 
lO 

i9 



LU 



I 



CO 

ffilco 

— 00 



UJ 

I oo 



OO I CO | LU 1 1 — 



cc 

o 

<■ 

COlLU 



DC 

a 

Q 
< 



<cl<lgj 



I 

o' 



i 

UJ 



CO CO, 

£ l>.l>. 



.'la 

Cu 



ICO 
O O O 



CM 

00 I 

o o 

LO I CO 



V) 

§ 

Li 

a. 
i Li- 

LU 
DC 



I CO LU 
< <C 



•i hi 



a. 

& 

cc 



o 

a. 

LL 
LL 

cc 



CD CO 
O O 

co 1 



co to 

CM CM 

op 



CD CO 
i— CM 



CO 

X 1 



±1 

+ 1 

O j 
CO 



CO 
LL 



i 



LU 

OC 

e 



CO 
CO 
LU 

o 

< 



LU 



LL 
O 

CO 
CO 
UJ 

Q 

< ) _J 

o 

2: 



CO 

3 



15 

CO, 



CL 

tb 

I CC 



LU 
3 



1 

O 

CL 
LL 
LU 
CC 



CO 



CO 
CM 



CO 

X 



c 
+ 

CM 



C 
UJ 

cc 

e 

CL — 



o 



CL 
I 



CO 
CO 
LU 

8 



£££ 
< o o 



UJ 

13 



CO 



o 

9 co oo 
cc 



f= 00 



UJ CO 

o < 



I oc 



LL 



§5 



00 



D O. < CL < l- 



LL 00 O 
O 00 < 
UJ CL 
CC CC 
LU O CO 
CO O V- 
s <; w 

CD 

CO <£ 
Z OO k 

a. cl 

DC CC 



J2g § 

LU CL 

S ' 



00 o 



c 



CL 
LL 
LU 

CC 



•3 



31 



BNSDOCtD: <EP. 



.1021048A2J_> 



EP 1021 048 A2 



,50 



(a) ^ 



C > 



23 



21 



(b) 



LEAD. IN AREA 


VOLUME & FILE 
MANAGER INFORMATION 


DATE AREA 
^24 


LEAD.OUT AREA 



(c) 

(d) 



DVD AREA 



;25 



(e). 



CONTROL INFORMATION 



VIDEO OBJECT 



SFl{ 



f | VOB GENERAL INFORMATION (VOB_GI) (SF_GI) f-27 

28 
29 



VOBU INFORMATION TABLE (SFI) 



VOBU INFORMATION (VOBU I) (SOB I) 



T 

31 



VOB_GI (SF_GI) 



(f) 



RBP 




CONTENTS 


NUMBER 
OF BYTES 


0 TO 3 


VOBU_Ns 
(SOBLNs) 


NUMBER OF VOBUs 
(NUMBER OF SOB Is) 


4 BYTES 


4 TO 7 


VOBLEND ADDRESS 
(OR LENGTH) 
(SOBU.SIZ) 


END ADDRESS OR 
LENGTH OF VOB I 

(NUMBER OF SECTORS PER SOBU) 


' 4 BYTES 


8 TO 8 


SUPPORT INFO . 


SUPPORT INFORMATION 


1 BYTE 


9 TO 9 


ARCHIVE FLAG 


ERASURE INHIBITION FLAG 

0: FREE, 1: SAVE PERMANENTLY 


1 BYTE 






TOTAL 


19 BYTES 



FIG.9 



32 



1021048A2 I _> 



EP 1 021 048 A2 



CO 
LU 

cc [ 

LU >- 
CO CD 



~ZL O 



CO 



LU 



O 

o 



ID 
CO 
: O 
> 

iO 



CD 
O 
> 

u_ 
o 

CO 
CO 
LU 
DC 
Q 
O 
< 



cc 
< 
I— 

CO 



o 

LU 



cr 
o 

CO 
CO 
LU 

cr 

Q 

o 
< 



LU 



DC 

o 

LU 
ZD 
— I 

CO 



CO 
CO 
LU 

cr 

Q 



cc 

CO 



CO 

o 
> 



CO 

o 

CO 



ZD 
CO 

o 
> 



0- 
CQ 
DC 



CO 
O 



CO 
CO 
LU 
DC 
Q 

Sg 

LU LU 



CO DC 
O O 
> — 



O 



CC 



CO 



cc 



4* 



LU 
DC 



Q_ O 

1\K 



LL 

CO O 
00 , 
LU CO 
DC CO 
Q LU 
Q OC 

« S 

< I q 

CO I LU 



CO LU 

<i3 



IS 



0- CL 

LL LL 

LU LL! 

CC " 



CO CO 

XX 



I 

c 

CD , . 
t- CSJ 



o 
o 



LU 
I 

m 

3 
1 

CO 



^- 
o 

Du 
I 



C 

UJ 
DC 

o 

CL 
t 



LU 

O 
<£ 
CL. 

CO 



DC 

§ 

o 

Q 

2: 



LU 



LU 
_J 
CO 



I CO 



o 

Q 

2 



22 



o <=> 



CO ^ 
LU O 



CO 
00 
LU 

o 



o < 

E co 



CO 

< h- 

_J DC 



CC 



oc 

ZD 



Q_ 
1 



o_ 

CO 
I — 

u_ 

o 



DC O 
LU — 

zc co 



£ 5 



LU 
> 



DC 
<£ 
I — 
CO 



LU CO 
O CO 
LU 
DC DC 
LU O 
CO O 

=> 

z: • • 

c 

• • ^ 

CO <C 

o o 

Du Q_ 
LL. LL. 
LU LU 

DC DC 



Q 
< 



^ LL 

^° 

O CO 
<C CO 

a. g 



CL. 



ZD 

o 

LL. 



O 

CL 
LL 
LU 
DC 



33 



BNSDOCIO <E P 102104BA2_L> 



EP 1 021 048 A2 



ZD 
CD 
O 
00 



CD 

£ 



CD 
O 
CO 

ZD 
CD 

5 



CD 
O 
CO 



CD 



ZD 
CD 
O 
CO 

ZD 
CD 
O 



ZD 
CD 
O 
00 

*w 

ZD 
CD 

£ 



m 
o 

CO 



CD 
O 
> 



^ o 

CD 2 

<c — 

CL 

I— 

CD UJ 

— cd 

Q < 

O CL 
< 

o_ 00 



LU O 
CO — 



o 

25 



O ro, 
I— ro 

LU 

cr 

ZD 
»— 
LD 

CL 
I 

— ^ 

o 

h- < 

CO CL 

cr 



— < 11 o 



CO 



00 

cr 

LL 
O 



o 

UJ 

e? 



o z: -J 



00 



o 
< 
cl 



LL 
O 



<0 



— Z UJ 

— cr 

^ ZD O 
O H H < 
< LU O LU 

a. 5^ — x 

CD ' 
00 < 

I — a. 







ZD 




CD 














CL 


ZD 
CD 
O 

7> 


PAT 






3 




CD 




O 




00 




DBU( 


PMT 


> 
















ID 




CD 




O 




CO 






o. 


ZD 
CD 
O 
?> 


PAT 






3 




CD 












0BU( 


PMT 


> 




















CD 




O 


I— 


00 






CL 


ZD 
CD 




9 


< 
CL 










3 




CD 




O 




CO 




0BU( 


CL 


> 













o z 



UJ -J 

^ CD. ^ , 

O 2 O CNJ. 

< — ^ co 

CL CL 

CD LU LL 

2 O 

— O 

Q <C Q 

Q Q_ < 

< LU 
CL 00 X 

h- o 

CC Z h 

LU CD 

00 — 

2: -J < 

- < Ql 



I p 







LL 








O 




00 


<c 






J— 


a. 


Q 




x 


o 


S 




o 








X 


Ed 


o 






ZD 
I 


H- 






CD 


O 








LU 








Z 








o 




cd 








-< 




-J 




Q_ 




< 












00 




CO 













I 




I 


Q 


LU 
CD 






CJ) 




CO 


I 




I 




LU 




C > 






o 




II 




Q 




CD 




CO 


| 




I 




LU 


ft 
It 


O 


o 




o 




CO 


i 

i J 




_J 




LU 




CD 






o 




II 




o 




o 




CO 


1 




1 


o 


i i i 


II 
II 


CD 


o 




CD 




00 






-J 




_J 




LU 




CD 






CD 




A 




CD 




CO 



o 








I— 








\- 




o 




LU 










I— 










O 




Si 




II 




CL 












5C 




CD 


LU 


O 








Q 








1— 








z: 


o 


a 




ZD 


<c 


< 




o 


CL 


CL 


00 


CD 






H- 




LL 






LU 


O 




2: 


O 




UJ 


o 




o 


CO 




_l 




2: 




CL 






<! 


00 


X 







NED 




; co 








; 


CE 


-j 




/ X 








: ° 


—j 








CL 


00 




X 


CO 




< 




X 


o 


CL 






II 


LL 






5= 


O 






o 


Q 






Q 


<C 






1— 


LU 


CL 


o 


UN 


X 




<: 


o 






CL 


CJ 





CD 
Li_ 



34 



BNSDOCID: <EP ia21048A2J.> 



EP 1 021 048 A2 



to 







CELL 


TjPMl 










-J 
1 




CEI 








IL 














ELL 


PMT 


o 












— i 








LLl 




O 


a. 














ELL 


PMT 


o 










Q- 


_ 




LL 






! £ 




CL 















i — 

LU _J > 

^ o ^ 
o 2: o 

^ ? 

CL CL 

O LU LL 

2= ^1 O 

CL 



O 
Q 



00 



DC -ZL 
LU CD 
00 — 



O 



< 

CL 



00 



< 

CL 
CO 



LL 
O 

o 



<0 



CO 



o 

LU 



o 2£ 



LU —J 

^ o ^ 

< — 3 

o. o. 

O LU LL 

2 ^ O 

O Cl 

CL C/> 



LU CD 
00 — 

2 si 



CL 



oo < ^ 

h Q- Q 



JS5 



3 



LU 

-< 

CL 



CO 



Cl 



11 = 

s: o Q 

— Z LU 

^ cd 

O I— — ; 
< UJ -J 

o o 

C/) < C/0 < 
\ — Q_ — Cl 











— 




o 






cd 


CL 




Li- " 


















/ \ 

>— ^ 






cd 






Q_ 








s 






CL 


















Cl 






I— 




o 






o 


Cl 




CL 








< 






CL 










CD 






CL 














Cl. 






t 












Cl 








* 




"P 


* 






* 


o 


Cl 




n 














CL 




c- 


> 




c 


) 




a 


- H 












Cl 


















CL 





cd 



LU —I 

^ o v: 

o z o 

7f — & 

CD LU LL 

S O 

Cl <C 



O 
Q 

2 



00 



QC 
LU CD 
00 — 

2^ 



o 



2 







LL 








O 
















O 




X 


cd 


3 




o 








WHI 


ian 


TO 














o 


o 








UJ 
















o 




o 








PA 


t] 


AL 
















CO 













C\J 
CD 



35 



BNSDOCtO <EP 1021048A2J_> 



EP 1 021 048 A2 



CO 



CD 
I - 




— I 


o 


LU 


II 


<J> 


o 




o 






LO 




_J 




I 




1 1 | 




o 






o 




II 




o 




o 




CO 






1 

I 





LU 


o 




il 










CO 






CO 




1 




1 

1 




1 1 1 










o 




II 




o 




o 




00 


CXI 




1 




_J 








1 1 1 




o 


II 




o 




o 




( r\ 

V/ 










Ij 




_J 




LU 




O 






o 




II 

o 








CO 



CO 
Q 

< 
oo 



LU 

o 



o 

LU 



o 
o 



o 

<: 



<C LU 



o o 



CO 







_L8 




CEl 


SCD=0 






:LL7 




LU 

o 






o 




SCD= 







<LJ 




_1 


O 


LLJ 


II 




L_) 




V ^ 




WJ 


LO 




_J 




-J 




LU 




O 






O 




II 
Q 




O 




CO 






—J 




_I 








LU 


O 


O 


II 


o 








CO 


CO 




— 1 




-J 








LU 


o 


O 


11 




Q 








CO 










— 1 




J 




LU 










O 




II 




O 




o 




CO 



o 

LU 
CO 



>- 00 

— I — 

00 

CO I — 
LU 2: 

-J — 
s o 
<c a. 

LU 

CO H- 

LU Q 
CO UJ 

ZZL UJ 
<£ O 
O ^ 

CO CO 

Q ^ 

< < 

CD 

o 

CO LU 

=1 £ 

LU -J 
O Q_ 



CO 



36 



BNSDOCID: <EP. 



102104&A2_L> 



EP 1 021 048 A2 




37 



BNSDOCID: <EP 1021O48A2_l_> 



EP 1 021 048 A2 



( START ) ^S10 



LOAD MANAGEMENT INFORMATION 




S13 



DETERMINE WRITE ADDRESS: 
Freear-FREE SPACE 



<S15 ( END > S14 



NO RECORDING 
SPACE" 

r 



OUTPUT EPG OUTPUT COMMAND TO STB; 
RECEIVE LATEST EPG INFORMATION 
FROM STB 



-S16 



DISPLAY EPG INFORMATION; 

USER DESIGNATES DESIRED PROGRAM 

FROM DISPLAYED EPG INFORMATION 



SEND SUPPORT INFORMATION 
OUTPUT COMMAND TO STB; 
RECEIVE SUPPORT INFORMATION FROM 
STB, AND FETCH STB I DENT I F I CAT I ON 
CODE; DESIGNATE PROGRAM IN STB 



•S18 



WRITE MANAGEMENT AREA; 

REGISTER VTS IN VMGI; GENERATE VTSI 

(WRITE SUPPORT INFORMATION) 



•S19 



INITIALIZATION FOR RECORDING 

RESET STC 

SET WRITE START 

ADDRESS IN DRIVE 

INITIALIZE FORMATTER 
SET CELL, VOBU, PG, PGC 
GROUPING (SET ALIGN PROCESS) 
TS PACKET RECEPTION/SETUP 
PROCESS 
ETC. 



•S20 



FIG.15 



38 



BNSDOCID: <EP. 



1021048A2J_> 



EP 1 021 048 A2 



SETUP FOR RECORDING START 
SET RECORDING START COMMAND IN FORMATTER 



-S21 




RECORDING END PROCESS 

FETCH SEGMENTATION INFORMATION FROM 

FORMATTER, WRITE INITIALIZING MANAGEMENT AREA 

WRITE IN VMGI 

WRITE IN VTSI 

(PGCI SETUP". SEGMENTATION INFORMATION, 

I -PIC INFORMATION, ETC.) 



-S28 



C END y -S29 

FIG. 16 



39 



EP 1 021 048 A2 



( START ) ^S30 




NG. 



FETCH STB IDENTIFICATION 
CODE FROM STB 







S32 


-S34 


ERROR PROCESS 



LOAD VMGI 



SELECT AND DETERMINE TITLE 
SET TO BE PLAYED BACK 



LOAD VTSI 
(SAVE PGCI IN WORK RAM) 



DISPLAY ALL TITLES (OR 
PGC OR PG) CORRESPONDING 
TO STB CONNECTED 



-S35 
-S36 

-S37 
-S38 



SELECT AND DETERMINE TITLE (OR 
PGC OR PG) TO BE PLAYED BACK 



FETCH SUPPORT INFORMATION 




( END y -S33 



S42 
) 



SET PERMISSION FLAG OF FF/FR USING I -PICTURE 



I 



PAT SUPPORT? 
NO 



S44 

i 



SET PERMISSION FLAG OF FF/FR USING PAT 



SET FF/FR INHIBITION FLAG 



S45 



DETERMINE PROGRAM NUMBER AND 
CELL NUMBER TO BE PLAYED BACK 



•S46 



FIG. 17 



40 



BNSDOCID: <EP 1021 048 A2_l_> 



EP 1 021 048 A2 



SEND TS PACKET PLAYBACK 
COMMAND TO STB VIA 
INTERNAL BUS 
INITIALIZE DISTRIBUTOR 
(SEND TS PACKET TO STB) ; 
SET V MIXING UNIT TO DISPLAY 
VIDEO SIGNAL FROM STB 



-S47 



CELL PLAYBACK PROCESS 



( END ) 




S52 

L 



COUNT UP CELL NUMBER | 



PLAYBACK END PROCESS 
( END ^-S55 



FIG. 18 



BNSDOCIO <EP 1021048A2„L> 



41 



EP1 021 048A2 



(cell playback process V S60 




DETERMINE PLAYBACK START ADDRESS 
(LBN) FROM CONTENTS OF PGCI 



SET DATA READ COMMAND IN DRIVE 



•S63 



•S64 




PLAYBACK TIME 
OUTPUT COMPATIBLE 
CHECK STB STB? 
IDENTIFICATION 
CODE no 

S74 S75 

S75 ^ j YES 

^DISPLAY 
V STC VALUE 



CHECK RETURN 






( RETURN 1 [ 






( 






S70 




S72 


■ > 





DISPLAY PCR VALUE 
N MANAGEMENT DATA 



DISPLAY PLAYBACK 
^FETCHED FROM STB 




TIMEj 



WAIT FOR END OF PLAYBACK 
OF VOBU OF INTEREST 



S77 



c 



RETURN 0 



>s78 FIG. 19 



42 



BNSDOCiD: <EP 1021048A2_t_> 



EP 1 021 048 A2 




43 



BNSDOCID: <EP 1021048A2J_> 



EP 1 021 048 A2 




EP 1 021 048 A2 



CM 
CM 

CO 



Z3 

cc 

CC LU 

^ cc 

— Q 
O =5 



LU 



8 



CM 
00 



A 



CO $ 



CC 
LU CO 
Li. CO 
CO LU 

s 

h- a. 



oo 
oo 

LU 

o 
o 

DC 
CL 



oc 



e 



GC 



o 

UJ 

a: 
o 



UJ 
CO 



1 



CO 
\— 
00 



§ CO 
IL CM 

(/) CO 
CO 
LU 

o 

& 



r> 
cc 
cc 

LU 



00 

>- 



LU 
CC 
ZD 
t- 
O 



< 

CD 
>- 

a. 

LU 

cr 

O 

CL 
i 



X 




BNSDOCID: <EP _102104SA2J_> 



45 



EP1021 048 A2 



(ft process using pat) - $101 




READ OUT START ADDRESS OF 
FIRST VOBU IN NEXT CELL 



-S104 



S103 
) 



READ OUT START 
ADDRESS TWO VOBUs 
AHEAD OF CURRENT ONE 



CLEAR I -PICTURE PLAYBACK 
INTERRUPT FLAG; 
SET I -PICTURE DATA READ 
COMMAND IN DRIVE (SET START 
ADDRESS, CONTINUOUS READ) 



-S105 




NTERRUPT FROM STB 
S108 YES 



READ OUT I -PICTURE START 
ADDRESS OF NEXT VOBU 







S109 


-S1 11 


SET STOP COMMAND 


IN DRIVE 





SET DATA READ COMMAND IN 
DRIVE (SET START ADDRESS, 
CONTINUOUS READ) 



•S11 



2 ( RETURN 1 ) 
S110 



( RETURN 0 ) -S113 

FIG. 23 



46 



.1021048A2_L> 



EP 1 021 048 A2 



(a) 



(b) 



TIME- 


TRANS- 




TIME- 




TRANS- 




TIME- 


TRANS- 




TIME- 


TRANS- 




STAMP 


PORT 




STAMP 


PORT 




STAMP 


PORT 




STAMP 


PORT 




ATS 


PACKET 




ATS 




PACKET 




ATS 


PACKET 




ATS 


PACKET 




a 


a 




b 




b 




d 




d 








f 


f 


















• • * " 














TIME- 


TRANS- 


TIME- 




TRANS- 




TRANS- 






TRANS- 


END 


PADDING 


STAMP 


PORT 


STAMP 




PORT 




PORT 






PORT 




CODE 


AREA 


ATS 


PACKET 


ATS 




PACKET 




PACKET 






PACKET 


31 


36 


a 


a 




b 




d 




d 






f 









PACK 


PES 


STREAM 


DATA 


PACK 


PES 


SECTOR 


DATA 




DATA 


HEADER 


HEADER 


BLOCK 


AREA 


HEADER 


HEADER 


DATA 


AREA 




AREA 


1 


6 


HEADER 


21 


2 


7 


HEADER 


22 




23 






11 








12 









(c) 





SECTOR 


SECTOR 




SECTOR 


SECTOR 


SECTOR 




SECTOR 




NO.O 


NO.T 




N0..15 


NO. 16 


NO. 17 




NO. 31 



ECC BLOCK 


ECC BLOCK 


ECC BLOCK 


ECC BLOCK 


ECC BLOCK 


STREAM BLOCK #1 


STREAM BLOCK J 





(e) 



(f) 



STREAM OBJECT U 298 



STREAM BLOCK #1 


SI 


"REAM BLOCK 1 


U 


ECC BLOCK 
#a 


ECC BLOCK 
#/? 


ECC BLOCK 


ECC BLOCK 
$8 


ECC BLOCK 



(g) 



(h) 



SECTOR 


SECTOR 




SECTOR 


SECTOR 




SECTOR 


SECTOR 


NO. 32 


NO. 33 




NO. 47 


NO. 48 




NO. 78 


NO. 79 





PACK 


PES 


SECTOR 


DATA 


PACK 


PADDING 


(i) 


HEADER 


HEADER 


DATA HEADER 


AREA 


HEADER 


PACKET 




3 


8 


12 


24 


4 


40 



(0 




TRANSPORT 


END CODE 


PADDING 






PACKET z 


32 


AREA 37 



PES HEADER 
9 



PADDING 
AREA 38 



FIG.24 



47 



BNSOOCID: <EP 1021 048 A2J_> 



EP 1021 048 A2 



STREAM BLOCK HEADER 1 1 



(b)~ 



TRANSPORT 
ACKET 
INFOR- 
MATION 611 



STREAM BLOCK 
INFORMATION 
612 



SECTOR DATA 
HEADER 
INFORMATION 
613 



TRANSPORT 
PACKET 
NFOR- 
MATION 621 



TRANSPORT 
RECORD PACKET 
TIME ATTRI- 
622 BUT I ON 
623 



STREAM 
BLOCK 
SIZE 
624 



STREAM 
BLOCK 
TIME 
DIFFERENCE 
625 



FIRST [TRANSPORT 
ACCESS PACKET 



POINT 
626 



CONNECTION 
FLAG 627 



NUMBER OF TRANSPORT 
PACKET 631 


TRANSPORT PACKET MAPPING 
TABLE 632 






I -PICTURE 
MAPPING 
TABLE 
641 


B,P-PICTURE 
START POSITION 
MAPPING TABLE 
642 


VIDEO 
PACKET 
MAPPING 
TABLE 643 


AUDIO 
PACKET 
MAPPING 
TABLE 644 


PROGRAM 
SPECIFIC 
INFORMATION 
MAPPING 
TABLE 645 



(d)- 



FIG.25 



(a)- 



SECTOR DATA HEADER 12 



(b)~ FIRST ACCESS POINT 651 



TRANSPORT PACKET 
CONNECTION FLAG 652 



FI6.26 

CONSTRA I NTS ON MPEG SPEC I F I CAT I ONS FOR SOB 



SYSTEM HEADER 


SHALL NOT BE INCLUDED 


SCR VALUE IN THE FIRST PACK OF A SOB 


ANY VALUE 


MPEG PROGRAM_END_CODE 


SHALL NOT BE INCLUDED 


STREAM. ID 


SHALL BE EQUAL TO BFh 




(PR 1 VATE_STREAM_2) 




IN ALL PES PACKETS 


FIG.27 



48 



BNSDOCID: <EP 1021048A2_L> 



EP1 021 048 A2 



STREAMER 

INFORMATION 

(STRI) 



STREAMER VIDEO MANAGER 




VIDEO MANAGER 


INFORMATION (STR.VMGI) 




INFORMATION 


STREAM FILE INFORMATION 
TABLE (SFIT) 




MANAGEMENT TABLE 
(VMGLMAT) 


ORIGINAL PGC 
INFORMATION (ORG.PGCIT) 


\ 


PLAYJJST SEARCH 
POINTER TABLE 
(PL.SRPT) 


USER DEFINED PGC INFORMATION 
TABLE (UD.PGCIT) 






TEXT DATA MANAGER (TXTDT.MG) 




APPLICATION PRIVATE DATA 
MANAGER (APDTJG) 


FIG. 28 



STREAMER VIDEO 
MANAGER INFORMATION 
(STR_VMGI) 



STREAM FILE INFORMATION 
TABLE (SFIT) 



ORIGINAL PGC 
INFORMATION (ORG.PGCI) 



USER DEFINED PGC 
TABLE (UD.PGCIT) 



INFORMATION 



TEXT DATA MANAGER (TXTDT.MG) 



APPLICATION PRIVATE DATA 
MANAGER (APDT_MG) 



STREAM FILE INFORMATION 
TABLE INFORMATION (SFITI) 



STREAM OBJECT STREAM . 
INFORMATION #1 (SOB.STI 80 



STREAM OBJECT STREAM 
INFORMATION (SOB.STI #n) 



STREAM F 
(SFI) 



ILE INFORMATION 



FIG. 30 



STREAM FILE INFORMATION 
TABLE INFORMATION (SFITI) 



STREAM OBJECT STREAM 
INFORMATION *1 (SOB_STI #0 



STREAM OBJECT STREAM 
INFORMATION fcn (SOB.STI ftn) 



STREAM FILE INFORMATION 
(SFI) 



FIG. 29 



STREAM FILE GENERAL 
INFORMATION (SF_GI) 



STREAM OBJECT INFORMATION 
SEARCH POINTER ttl (SOBI_SRP #0 



STREAM OBJECT INFORMATION 
SEARCH POINTER ttn (SOBLSRP ftn) 



STREAM OBJECT 
INFORMATION ftl (SOB I ftO 



STREAM OBJECT 
INFORMATION ftn (SOB I ftn) 



49 



1021048A2 J > 



EP 1 021 048 A2 



STREAM FILE GENERAL INFORMATION (SF_GI) 





CONTENTS 


NUMBER OF BYTES 


(1) SOBI_Ns 


NUMBER OF SOB Is 


2 


(2) SOBU_SIZ 


NUMBER OF SECTORS PER SOBU 


2 


(3) MTU_SHFT 


MAPPING TIME UNIT SHIFT 


1 


(4) RESERVED. 


RESERVED 


1 




TOTAL 


6 


FIG. 31 



STREAM OBJECT 
INFORMATION 
(SOB I) 



SOBI Gl 



MAPPING LIST (MAPL) 



ACCESS UNIT DATA (AUD) 
(OPTIONAL) 



FIG. 32 



STREAM OBJECT INFORMATION GENERAL INFORMATION (SOBI_GI) 





CONTENTS 


NUMBER OF BYTES 


(1) SOB_TY 


SOB TYPE 


1 


(2) SOB_REC_TM 


SOB RECORDING TIME 


5 


(3) SOB_STI_N 


SOB STREAM INFORMATION NUMBER 


1 


(4) AUD_FLAGS 


ACCESS UNIT DATA FLAGS 


1 


(5) SOB_S_APAT 


SOB START APAT 


6 


(6) SOB_E_APAT 


SOB END APAT 


6 


(7) SOB_S_SOBU 


FIRST SOBU OF THIS SOB 


4 


(8) MAPL_ENT_Ns 


NUMBER OF MAPPING LIST ENTRIES 


4 




TOTAL 


28 



FIG. 33 



50 



BNSDOCIO <EP 1021048A2_I_> 



EP 1 021 048 A2 



ACCESS UNIT DATA 
(AUD) (OPTIONAL) 



FIG. 34 



ACCESS UNIT GENERAL 
INFORMATION (AU_6l) 



ACCESS UNIT END MAP 
(AUEM) (OPTIONAL) 



PRESENTATION TIME STAMP 
LIST (PTSL) (OPTIONAL) 



ACCESS UNIT GENERAL INFORMATION (AU_GI) 





CONTENTS 


NUMBER OF BYTES 


0) 


AU.Ns 


NUMBER OF ACCESS UNITS 


4 


(2) 


AUSM 


ACCESS UNIT START MAP 
(MAP_ENT_Ns ELEMENTS) 


(MAPL_ENT_Ns+7) div 8 




TOTAL 


(MAPL_ENT_Ns+7) div 8 + 4 



FIG. 35 



AUSM 



FIRST 

ELEMENT DDL 
OF AUSM 
FIRST 
BYTE OF 
AUSM 



LAST 
BYTE OF 
AUSM 
(WITH 3 
PADDING 
BITS) 



b5 
b4 
b3 
b2 
bl 
bO 



b7 

SECOND b 6 
BYTE OF b5 
AUSM b4 



b7 
b6 
b5 
b4 
b3 
b2 
b1 
bO 




LAST 
" ELEMENT 
OF AUSM 



SOBU %\ 



SOBU %2 



SOBU #3 



SOBU #4 



SOBU #5 



SOBU $& 



SOBU tl 



SOBU $8 



SOBU #9 



SOBU #10 



SOBU $1 1 



SOBU #12 



SOBU #1 MAPL_ENT_Ns-4 



SOBU fl1MAPL_ENT_Ns-3 



SOBU #1MAPL_ENT_Ns-2 



SOBU #1MAPL_ENT_Ns-1 



SOBU #1MAPL_ENT_Ns 



_0 /"PADDING BITS 



FIG. 36 



)SOB 



51 



BNSDOCID: <EP 1021048A2J_> 



EP 1 021 048 A2 



AUSM_pos(1)= 
AUEM_pos(1)= 

AUSM_pos(2) 
AUEM_pos(2) 

AUSM_pos(3) 
AUEM_pos(3) 




=D b2JL.0_ 
=7—51 0 1 



-8^ 

=9- 



b6 

b5 
b4 



0 0 



HA 



SOB 
SOBU 81 
SQBU U 



SOBU 83 



SOBU 84 



SOBU #5 



SOBU 86 



SOBU 87 



SOBU 88 



SOBU 89 



FIG. 37 



>AU Si 




FIG. 38 



PACK 
HEADER 



14 BYTES 



-ONE STREAM PACK- 



STREAM PES PACKET 



STRUCTURE OF THE STREAM DATA AREA WITHIN A STREAM PES PACKET 






STREAM PES PACKET (2034B) 




STREAM DATA AREA (2027B) 


APPLICATION PACKET AREA 
I K — 3H 


PACK 
HEADER 
14B 


PES 

HEADER 
6B 


SUBSTR. 
ID 

1B 


APPLI- 
CATION 
HEADER 9B 


APPLICATION 
HEADER EXT. 
(OPTIONAL) 




APPLICATION PACKETS 
WITH APPLICATION 
TIMESTAMPS 



PARTIAL 

APPLICATION 

PACKET 


APPL. 
TIME- 
STAMP 


APPLICATION 
PACKET 




48 
-< — >- 


AP LEN 
-< >- 



APPL 
TIME- 
STAMP 



APPLICATION 
PACKET 



PARTIAL 

APPLICATION 

PACKET 



FIG. 39 



52 



BNSOOCID: <EP 1Q21048A2J_> 



EP 1 021 048 A2 



APPLICATION HEADER 



FIELD 


NUMBER 
OF BITS 


NUMBER 
OF BYTES 


VALUE 


COMMENT 


(1) VERSION 


8 


1 


Olh 




(2) AP_Ns 


8 


1 






(3) F I RST_AP_OFFSET 


16 


2 






(4) EXTENS 1 ON_HEADER_ 1 NFO 


2 


1 


00b, 10b, 11b 




(5) RESERVED FOR CCI.ESC 


1 


Ob OR 1b 




(6) RESERVED 


5 


11111b 




(7) SERVICEJD 


16 


2 






(8) MAX BRJ-0G2 


8 


1 






(9) SMO BS L0G2 


8 


1 








TOTAL 


9 







FIG. 40 



102104SA2J > 



53 



(19) 



J 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 




(12) 



(88) Date of publication A3: 

02.10.2002 Bulletin 2002/40 

(43) Date of publication A2: 

19.07.2000 Bulletin 2000/29 

(21) Application number: 00100595.8 

(22) Date of filing: 12.01.2000 



{ ii) EP 1 021 048 A3 

EUROPEAN PATENT APPLICATION 

(51) mtci7. H04N 9/804, H04N 5/783 



(84) Designated Contracting States: 
DE FR GB 

Designated Extension States: 
AL LT LV MK RO SI 

(30) Priority: 14.01.1999 JP 784299 

(71) Applicant: KABUSHIKI KAISHA TOSHIBA 
Kawasaki-shi, Kanagawa-ken (JP) 



(72) Inventors: 

• Ando, Hideo 

1-1 Shibaura 1-chome Minato-ku Tokyo 105 (JP) 

• Uyama, Kazuyuki 

1-1 Shibaura 1-chome Minato-ku Tokyo 105 (JP) 

• Kikuchi, Shinichi 

1-1 Shibaura 1-chome Minato-ku Tokyo 105 (JP) 

(74) Representative: Henkel, Feiler, Hanzel 
Mohlstrasse 37 
81675 Munchen (DE) 



(54) Digital video recording system and its recording medium 



(57) In a DVD recording/playback system, a set top 
box STB (83) receives an MPEG transport stream con- 
stituted by a plurality of transport packets, and a format- 
ter (90) extracts support information indicating if man- 



agement information included in the transport packets 
includes predetermined items. A disc drive (51) that 
records data on a recording medium having a manage- 
ment area and data area records the support informa- 
tion in the management area. 



v RAM-DISC 



CO 

< 

00 

o 



CM 

o 





V0BU GROUPING. J FORMATION 
ENCODE SEfUPsV'ETC. 



SEND TS PACKET 
BY ADJUSTING 
TRANSFER TIME 
AUDIO SIGNAL 



3v mixing unitHframe uemory| 



SATELLITE 
ANTENNA 



VIDEO SIGNAL 



TEXT DATA, DISPLAY 



G. 14 



J — T 1 

SUPPORT MANAGEMENT 
INFORMATION DETECTOR 


MANAGEMENT 
DATA 


SUPPORT INFORMATION 
ADDING UNIT 


GENERATOR 
~ m BOB 


WORK RAM j— 80A 


MAIN MPU 




^iZy^SIGNAL 



KEY INPUT UNIT 
(PUY KEY, STOP KEY, 
MARKER KEY. ETC. ) _ 



-104 



OL 
HI 



Printed by Jouve, 7S001 PARIS (FR) 



BNSDOCID: <EP 1021048A3_I_> 



EP 1 021 048 A3 




European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 00 10 0595 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION <tntC1.7) 



EP 0 724 264 A (KABUSHIKI KAISHA TOSHIBA) 
31 July 1996 (1996-07-31) 

* column 11, line 23 - column 14, line 25 
* 

* column 21, ,line 3 - column 26, line 11 * 

* column 29, line 27 - column 37, line 56; 
figures 4-6,25-44 * 

EP 0 866 461 A (SONY CORPORATION) 
23 September 1998 (1998-09-23) 

* the whole document * 



The present search report has been drawn up for afi claims 



1*3,6,7, 
9-11 



H04N9/804 
H04N5/783 



1,3,6,7, 
9-11 



TECHNICAL FIELDS 
SEARCHED (lntCI.7) 



H04N 



Place of search 

THE HAGUE 



Date of completion of the soarch 

14 August 2602 



Verleye, J 



CATEGORY OF CITED DOCUMENTS 

X : particularly relevant if taken atone 

Y : particularly relevant it combined with another 

document of the same category 
A : technological background 
O : non-written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but pubPshed on, or 

alter the tHino dale 
D : document cited in the application 
L : document cited lor other reasons 



& : member ol the same patent family, corresponding 
document 



2 



BNSDOCID: <EP 1021048A3_I_> 



EP 1 021 048 A3 



ANNEX TO THE EUROPEAN SEARCH REPORT 
ON EUROPEAN PATENT APPLICATION NO. 



EP 00 10 0595 



This annex lists the paten! family members relating to the patent documents cited in the above-mentioned European search report 
The members are as contained in the European Patent Office E DP file on . 

The European Patent Office is in no way liable for these particulars which are merely given for the purpose of information. 

14-08-2002 



Patent document 
ciled in search report 


Publication 
date 


Patent family 
. member(s) 


.Publication 
date 


EP 724264 A 


31-0/-199D 


AT 
A 1 




15-12-1998 




AT 


191292 T 


15-04-2000 






CA 


21683Z/ Al 


31-07-1996 






CN 


1134583 A 


30-10-1996 






DE 


69601039 Dl 


14-01-1999 






DE 


69601039 T2 


24-06-1999 






OE 


69607489 Dl 


04-05-2000 






DE 


69607489 T2 


21-09-2000 






EP 


0724264 A2 


31-07-1996 






EP 


0872839 A2 


21-10-1998 






JP 


2747268 B2 


06-05-1998 






JP 


8273304 A 


18-10-1996 






JP 


2857126 B2 


10-02-1999 






JP 


10074379 A 


17-03-1998 






JP 


2875237 B2 


31-03-1999 






JP 


10074380 A 


17-03-1998 






KR 


209846 Bl 


15-07-1999 






KR 


209851 Bl 


15-07-1999 






KR 


220529 Bl 


15-09-1999 






TW 


434531 B 


16-05-2001 






US 


6118927 A 


12-09-2000 






US 


5870523 A 


09-02-1999 


EP 866461 A 


23-09-1998 


CN 


1199906 A 


25-11-1998 






EP 


0866461 A2 


23-09-1998 








JP 


10322661 A 


04-12-1998 








US 


6282320 Bl 


28-08-2001 


i 

i 



u For more 



details about this annex : see Official Journal of the European Patent OIHce, No. 1 2^82 



102104BA3 J_ > 



This Page is Inserted by IFW Indexing and Scanning 
Operations and is not part of the Official Record 



Defective images within this document are accurate representations of the original 
documents submitted by the applicant. 

Defects in the images include but are not limited to the items checked: 

□ BLACK BORDERS 

□ IMAGE CUT OFF AT TOP, BOTTOM OR SIDES 

□ FADED TEXT OR DRAWING 

□ BLURRED OR ILLEGIBLE TEXT OR DRAWING 

□ SKEWED/SLANTED IMAGES 

□ COLOR OR BLACK AND WHITE PHOTOGRAPHS 

□ GRAY SCALE DOCUMENTS 



M LINES OR MARKS ON ORIGINAL DOCUMENT 

□ REFERENCE(S) OR EXHD3IT(S) SUBMITTED ARE POOR QUALITY 

□ OTHER: . . ... ■ . 



IMAGES ARE BEST AVAILABLE COPY. 
As rescanning these documents will not correct the image 
problems checked, please do not report these problems to 
the IFW Image Problem Mailbox. 



BEST AVAILABLE IMAGES 




